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AMPLIMO LEVERT NU 
RINGKERNTRAFO'S MET 


DE BESTE GARANTI 


Het KEMA-KEUR-merk is de beste 
garantie voor kwaliteit en veiligheid. 
De AMPLIMO ringkerntrafo’s dragen 
nu dit keurmerk. 

AMPLIMO is de eerste in Nederland 
met KEMA-KEUR voor liefst 170 
types van 15 t/m 1000VA. 

Alle zijn uit voorraad leverbaar. 


Topkwaliteit in kombinatie met een 
uitstekende veiligheid. 
De wikkeling met de gevaarlijke net- 
spanning is volledig omgeven door 
een drievoudige isolatie, welke liefst 
5000V kan weerstaan. 


® 


AMPLIMO b.v. 
Vossenbrinkweg 1 
7491 DA Delden 


AL 





Het ontwerpen en 
wikkelen geschieden Ne 
zeer zorgvuldig en de eind- œ% y 
controle wordt uitgevoerd volgens “x, 
ISO9003. ' 
Zelfs trafo's met andere wikkelingen 
in de 12 standaard formaten worden 
met het beroemde KEMA-KEUR ge- 
leverd! 


Duidelijk advies over de toe te passen 
zekering voor optimale veiligheid. 
Het voldoen aan de strenge KEMA 
eisen heeft bij AMPLIMO nauwelijks 
of geen prijsverhoging tot gevolg. 


Telefoon 074 376 3765 
Fax 074 376 3132 








LAATSTE BOEKENNIE 


Uw eerste 
adres voor 
halfgeleiders 
en micro- 
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| De serie het basisboek is speciaal bedoeld voor de en- 

Ì thousiaste en geïnteresseerde PC-gebruiker die zich 
de nodige kennis van enkele standaard programma's 
zo snel mogelijk eigen wil maken. 


Eris gekozen voor een stapsgewijze opzet in alle hoofd- 
stukken: 

- eerst wordt een onderwerp algemeen uitgelegd 

- vervolgens kunt u door het uitvoeren van een opdracht 
zelf aan de slag 

- in appendix b wordt in het algemeen de uitwerking 
van de opdracht beschreven 

- het onderwerp wordt afgesloten met enkele tips en 
trucs en aanwijzingen voor de uitvoering van de op- 
dracht 





grenen) eagen) eee) 


De eerste zes hoofdstukken behandelen de basisfuncties aan de hand van opdrachten, voor- 
beelden, tips en trucs. Bovendien komt u alles te weten over de mogelijkheden van het pro- 
gramma om gegevens af te drukken, in het scherm te tonen, te importeren en te exporteren. De 
laatste hoofdstukken gaan over de specialiteiten van het programma, bijvoorbeeld een inge- 
bouwde macro-taal of extra tekstverwerkingsopties. in de bijlagen vindt u een praktische installatie- 
handleiding en de uitwerking van de opdrachten uit het boek. 

Titel: Vraagbaak Excel 7 Windows 95 
Bestelnummer 7 

vraagbaak 9 
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Deze vraagbaak kunt u gebruiken als eerste kennismaking met 
Excel 7 voor Windows 95, maar het is ook een ideaal naslag- 
werk. In hoofdstuk 1 leest u alles over de installatie en de grond- 
beginselen van Excel 7. 

In hoofdstuk 2 worden de werkmappen en werkbladen bespro- 
ken. Hoofdstuk 3 gaat over basisbewerkingen en in hoofdstuk 
4 komen formules en functies aan bod. 

In hoofdstuk 5 en 6 komen werkbladopmaak en belangrijke 
functies aan de orde en hoofdstuk 7 behandelt het afdrukken 
van werkbladen. 

In hoofdstuk 8 leert u werkbladen controleren, documenteren 
en beveiligen. Hoofdstuk 9 gaat over grafieken en objecten, 
hoofdstuk 10 bespreekt het werken met databases en hoofd- 
stuk 11 draaitabellen. 

In hoofdstuk 12 gaat u eigen dialoogvensters maken. Hoofd- 
stuk 13 bespreekt macro's en het laatste hoofdstuk gaat over 
werken met andere toepassingen. 

Handige bijlagen en een index besluiten het boek. 


WJ ideaal naslagwerk 


tips & trucs | 
@ praktijkgericht 





Titel: Muziek op Internet 


B ummer: 750847 
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Hewlett 


: Aer Packard 
Internet, het wereldwijde communicatienetwerk voor t t 
computers, groeit nog dagelijks en de mogelijkheden nterne i EBV is een toonaangevende 
van het net zijn zeer omvangrijk. Europese doe your 
halfgeleiders en micro-systemen. 
Met in1995 een omzet van meer 
dan 600 miljoen hfl. In het 
centrale magazijn in München 





Dit boek richt zich op wat er met Internet mogelijk is in 
relatie tot muziek. U kunt bijvoorbeeld informatie inwin- 
nen over artiesten, componisten, nieuwe muziek- 
uitgaven, distributeurs, fanclubs en nog veel meer. Of u 
kunt met andere muziekliefhebbers discussiéren over 


geliefde of juist verguisde muziekstukken. En dat niet brrr liggen 40.000 verschillende 

alleen op het gebied van popmuziek, maar ook op het ý partnummers met een waarde 
Overzichtelijk en compoc e van 120 miljoen hfl. gereed. Meer 

geveer alle andere categorieën. dan 340 medewerkers staan in 
Lo mei voor kwaliteit: Voor snelle 


In deel 1 komen praktische zaken aan de orde als be- 
nodigde hard- en software, Internet-aanbieders en kos- 
ten. Ook wordt uitgelegd hoe u zich bijvoorbeeld abon- 
neert op een nieuwsgroep en hoe u bestanden kunt 
downloaden. 


In deel 2 is een beschrijving van een groot aantal zeer diverse sites, uiteenlopend van klassieke Bv ELEKTRONK 


muziek tot rap-muziek. Met dit gedeelte als gids vindt u snel wat u zoekt, of het nu gaat om het AUTHORIZED DISTRIBUTOR FOR SEMICONDUCTORS AND MICROSYSTEMS 
downloaden van een muziekfragment van Schubert of het abonneren op een nieuwsgroep voor Planetenbaan 2 

basgitaristen. NL-3606 AK Maarssenbroek 

Tel. (0346) 58.30.10, Fax (0346) 58.30.25 


levering, vakkundigheid en 
concurrerende prijzen. 
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gebied van jazz, klassiek, country and western, en on- 























VITROHM 


Europees markt- 

leider in 

draadgewonden 

weerstanden, 

tevens 

E kool- en metaal- 
filmweerstanden 

E netwerken 

E hybride- 
schakelingen 


MEC 


Modulaire print- 

schakelaars 

E standaard 
en SMD- 
uitvoering 

E verlichte 
versies 

B groot aantal 
accessoires 
in 7 kleuren 


MINIMOTOR 


E miniatuur 
DC motoren 
van @ 10 mm 
tot Ø 35 mm 
E vertraging tot 
1.000.000 : 1 
E borstelloze 
servomotoren 
B motor- en 
tachogeneratoren 
B impulsgevers 


BELLING LEE 


E netontsto- 
ringsfilters 

E zekeringen en 
houders 

B meerpolige 
ronde 
connectoren 

E DiL-relais 

E trekmagneten 





MORS 


Een wereld van 
tuimel-, wiptoets-, 
drukknop-, schuif- 

en codeerschakelaars 
in miniatuur en 
standaarduitvoering 





AMROH: 
naam als het gaat om de levering van 
elektronische en elektromechanische 

componenten; meet- en regelapparatuur 
en hoogwaardige HI-Fl-produkten. 


internationaal een gerenommeerde 


AMROH 


NEDERLAND: Hogeweyselaan 227 
1382 JL Weesp 
Postbus 370 
1380 AJ Weesp 
Tel: 02940-15350 
Fax: 02940-12782 


BELGIE: 


Amroh Electronics Belgium 
Nieuwdreef 7 

B-2328 Hoogstraten 
Tel/Fax: 03/3150606 


DUITSLAND: Amroh Electronics GmbH 
Postfach 460201 
D-47856 Willich 


Tel: 02154-428461 











SCHRACK 


Schrock Relays. Our Selection ~ Your Solution. 


Een 
relaisprogramma 
met allure: 
E vermogens- 
printrelais 
van 1 tot 40 Amp. 
W insteekrelais 
tot 30 Amp. 
@ accessoires, o.a. 
relaisvoeten met 
insteekmodules 





NCC 


Toonaangevende 
fabrikant van 
elektrolitische 
condensatoren 
in axiale, 

radiale en 

SMD uitvoering 





POTENTIOMETEAS AND THINKERS 


SFERNICE 


EB cermet enkel- 
en meerslagen 
trimmers 

E industriële 
potentiometers 
in een grote 
verscheidenheid 

E vermogens- en 
precisie 
weerstanden 





SIFAM 


Europa's 

grootste produ- 

cent van: 

E kunststof 
knoppen 

E paneelmeters 

H proces- 
indicatoren 

B glasvezel- 
componenten 
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f analoge 
Verkrijgbaar bij: De Muiderkring e 
Internet, het wereldwijde communicatienetwerk voor compu- Isolatie- 


ters, groeit nog dagelijks en de mogelijkheden van het net zijn 


zeer omvangrijk. Op Internet is veel informatie te vinden over ver sterker 
* 












games, maar u kunt er ook spelen. Elke game die u maar kunt 
bedenken heeft waarschijnlijk wel een nieuwsgroep, een FTP- 
vel ne inate site of een Web-pagina. U kunt de nieuwste demo's bekijken, 
games downloaden of via het net spelen met tegenstanders 

Ee over de hele wereld. In deel 1 van dit boek komen praktische 
aen eri EN zaken aan de orde als benodigde hard- en software en Interne- 
taanbieders. Ook wordt uitgelegd hoe u bijvoorbeeld bestan- 


Boordevol sites den zoekt en overzet naar uw computer. Deel 2 beschrijft een 
groot aantal games. Met dit gedeelte als gids vindt u snel de h H EWLETT 
beste nieuwsgroepen, Web-sites of discussiegroepen. Er zijn | 
aparte hoofdstukken over spelfabrikanten, controlespellen, PAC KA RD 
arcadespellen en interactieve Internet spellen. Voor liefheb- 
bers van games is er op Internet veel te ontdekken, onder an- 


dere dat ze minder slaap nodig hebben dan ze altijd dachten! 


k Windows 95 


bij: De Muiderkring 


De serie het basisboek is speciaal bedoeld voor de en- {£> 

thousiaste en geïnteresseerde PC-gebruiker die zich | WINDOWS® 95 

de nodige kennis van enkele standaard programma’s | 

zo snel mogelijk eigen wil maken. Er is gekozen voor 

een stapsgewijze opzet in alle hoofdstukken: 

- eerst wordt een onderwerp algemeen uitgelegd 

- vervolgens kunt u door het uitvoeren van een opdracht 
zelf aan de slag 

- in appendix b wordt in het algemeen de uitwerking 
van de opdracht beschreven 

- het onderwerp wordt afgesloten met enkele tips en 
trucs en aanwijzingen voor de uitvoering van de op- 
dracht 


De eerste hoofdstukken behandelen de basisfuncties 
aan de hand van opdrachten, voorbeelden, tips en trucs. 
Bovendien komt u alles te weten over de mogelijkhe- 
den binnen Windows 95. De laatste hoofdstukken gaan 
over de specialiteiten en instellingen van Windows 95. 
In de bijlagen vindt u een praktische installatiehandleiding en de uitwerking van de opdrachten 
uit het boek. 








Alle ins en outs van 3D-tekenen 
Met praktijkvoorbeelden en opdrachten 
3D-Toolkit met AutoLISP-programma’s 


Werken in een 3D-ruimte is inmiddels een integraal deel van 
het ontwerpproces. ledereen die meer doet dan één aanzicht 
maken, moet wel werken in de 3D-ruimte en dat geldt ook voor 
iedereen die een perfecte presentatie wil maken. Dit boek is 
ontwikkeld als een praktijkgerichte studiehandleiding. In de 
hoofstukken 1 tot en met 14 maakt u stap voor stap kennis met 
de verschillende technieken en opdrachten die voor het 3D- 





tekenen nodig zijn. Elk hoofdstuk bevat een les waarin één of De voordelen van de HCPL-78xx ten opzichte 
meer essentiële punten van het 3D-tekenen wordt behandeld. van traditionele manieren van stroommeting, zoals 
Per hoofdstuk wordt niet alleen geleerd hoe u bepaalde con- bijvoorbeeld hallsensoren, zijn: 

cepten aanpakt, maar krijgt u ook ervaring in het werken met @ compacte constructie 

modellen. De hoofdstukken 15 en 16 zijn specifiek voor de @ automatische verwerking mogelijk 
vakrichtingen werktuigbouw en architectuur. Hierin wordt een ® aanzienlijk betere common mode rejection 
voor die disciplines kenmerkend model ontwikkeld, en krijgt u ® lagere offset drift 

de gelegenheid twee praktijkvoorbeelden volledig uit te wer- @ ongevoelig voor magnetische invloeden 


ken met behulp van alle technieken die u in de eerdere 14 hoofdstukken heeft leren hanteren. 
Hoofdstuk 17 is de zogenaamde 3D Toolkit. Hierin staan 53 kant en klare AutoLISP-program- 
ma’s waarmee uw werk in 3D aanzienlijk kan worden versneld en uitgebreid, en die u kunt 
gebruiken alsof het gewone AutoCAD-opdrachten zijn. 


Om met dit boek aan de slag te kunnen, moet u de basis-opdrachten van AutoCAD kennen. U 
hoeft geen AutoCAD-expert te zijn en u hoeft niets te weten van programmeren in AutoLISP. Het ER\/ FL EK TRONK 


* ca. adviesprijs bij bestelling van tenm. 100 stuks, 
ex. BTW 


boek is ontwikkeld aan de hand van AutoCAD versie 13, maar heeft u deze versie niet, dan kunt ROE ne ENE eee 
u grote delen van het boek gebruiken voor de versies 11 en 12. Kortom, dit boek leert u op een 
effectieve wijze alle ins en outs van het 3D-tekenen. NL-3606 AK Maarssenbroek, Planetenbaan 2 


Tel. (0346) 58.30.10, Fax (0346) 58.30.25 
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REDACTIONEEL 


EDA … Inmiddels 
een begrip (een 
must?) binnen de 
elektronica 


De afgelopen jaren is de trend in de ontwikkeling gegaan 
van hardwarematige proefseries en nulprodukten naar 
softwarematige analyses en produktontwikkeling op de 
computer. Vooral is deze trend merkbaar voor produkten 
waarin de functionaliteit en de verkoopbaarheid gedeeltelijk 
of geheel worden bepaald door de ingebouwde elektronica. 


Onder de noemer EDA, Electronic Design Automation, is de 
afgelopen jaren een hele range van softwareprodukten op 
de markt gebracht die aangeschaft kunnen worden als 
‘gereedschap’ ten behoeve van de produktontwikkeling. 
Bedrijven die op dit terrein ‘bijblijven’ als doelstelling willen 
en/of moeten realiseren, kost dat moeite, zowel inhoudelijk 
als financieel. Met het oog op die moeite organiseerde de 
brancheorganisatie voor Industriële Elektronica via haar 
federatie Het Instrument op donderdag 9 mei een 
zogenoemde EDA Dag in het hotel Mecure in Nieuwegein. 


Deze gezamenlijke uitgave van Het Instrument en 
RB Elektronica bundelt de resultaten van deze dag. 


Veel plezier. 


Dirk Scheper 
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THEMA: Electronic Design Automation 


INTRODUCTIE: 


ONTWERPAUTOMATISERING, 


Rendement op investeringen in software-gereedschap ter discussie gesteld 


De ontwikkeling van produkten gebeurt steeds meer 
softwarematig. Dat geldt zeker voor produkten waarin de 
functionaliteit en de verkoopbaarheid gedeeltelijk of geheel 
worden bepaald door de ingebouwde elektronica. 


Onder de noemer EDA, Electronic Design 
Automation, is de afgelopen jaren een hele 
range van softwareprodukten op de markt ge- 
bracht die aangeschaft kunnen worden als 
‘gereedschap’ ten behoeve van de produktont- 
wikkeling. Bedrijven die op dit terrein ‘bijblijven’ 
als doelstelling willen en/of moeten realiseren, 
kost dat moeite, zowel inhoudelijk als financieel. 
Met het oog op die moeite organiseerde de 
brancheorganisatie voor Industriële Elektronica 
via haar federatie Het Instrument op donderdag 
9 mei een zogenoemde EDA Dag in het hotel 
Mecure in Nieuwegein. Deze gezamenlijke uit- 
gave van Het Instrument en RB Elektronica bun- 
delt de resultaten van deze dag. 


State of the Art & Cost of 
Ownership 


Het concept van de EDA Dag is tamelijk uniek. 
In de ochtend presenteren de leveranciers de 
State of the Art, in drie parallelsessies van elk 
zes lezingen, gratis toegankelijk, gericht op ‘de 
man achter het toetsenbord’. Het middag- 
gedeelte bestaat uit een samenhangend 
seminarprogramma waarin begrippen als Cost 
of Ownership en Return on Investment centraal 
staan. Gebruikers die een investering in de toe- 
komst overwegen kunnen in dit seminar van 
collega’s leren wat ‘geloof en werkelijkheid’ is 
bij het nemen en uitvoeren van een beslissing 
te investeren in softwaretools voor produkt- 
ontwikkeling. 


Het middagprogramma is gericht op het mana- 
gement van bedrijven die zelf produkten ontwik- 
kelen en slechts tegen betaling toegankelijk. De 
sprekers in dit gedeelte zijn afkomstig van be- 
drijven met gebruikservaring, zoals Chess En- 
gineering, HSA, Scantech en AGFA Gevaert. Dit 
deel van het programma staat onder voorzitter- 
schap van de heer Dick Rakhorst, voorzitter van 
de Development Club een vereniging van vijfen- 
dertig onafhankelijke ontwikkelbedrijven. 


Het eerste gedeelte van deze uitgave omvat de 
bijdrage van de sprekers van de middagsessie: 


Cost of Ownership. 


Embedded Software, VHDL 
en E-CAD 


De achttien presentaties in het ochtendgedeelte 
zijn verdeeld over drie parallelthema’s: 
Embedded Software, VHDL hard- & software 
definitietalen en E-CAD hardware design en en- 
gineering. Deze driedeling geeft aan waarover 
het gaat als gesproken wordt over de huidige 
State of the Art van ontwerptechnologie en vormt 
ook de hoofdstukindeling van het vervolg van 
deze uitgave. 


Embedded Software Design Tools is die soft- 
ware die gebruikt wordt om de software te ont- 
wikkelen die nodig is om moderne elektronica- 
hardware de functionaliteit te geven die de ap- 
plicatie vraagt; software waarmee software kan 
worden gemaakt die zorgt dat het apparaat 
‘werkt’. 


Met de groeiende complexiteit van produkt- 
ontwikkeltrajecten wordt het steeds meer nood- 
zakelijk om vooraf een goede structuur aan te 
brengen waarbinnen de beoogde ontwikkeling 
inderdaad softwarematig kan worden gereali- 
seerd. VHDL, Very High Level Hardware 
Definition Language, een beschrijvingstaal op 
een bepaald abstractieniveau, is een software 
hulpmiddel datdaarbij langzamerhand onmis- 
baar wordt. 


Het onderdeel E-CAD omvat de verhalen die 
inzicht geven in wat nu beschikbaar is aan tools 
voor het daadwerkelijk realiseren van een elek- 
tronische schakeling die produceerbaar en test- 
baar is. 


Elk jaar een EDA/Enginee- 
ring software show 


De Nederlandse Brancheorganisatie voor Indus- 
triéle elektronica organiseerde in mei 1995 voor 
het eerst een EDA/engineering software show. 
Deze technologieshow was toen onderdeel van 


de branche vakbeurs Electronics. Met vier an- 
dere shows, Test & Measurement, Mechatronics 
& Automation en Components & Production 
spraken de leveranciers toen een brede groep 
aan van (potentiële) ontwikkelaars, fabrikanten 
en gebruikers van elektronicaprodukten. 


In navolging van de in 1994 succesvol georga- 
niseerde separate Test & Measurement Dagen, 
is nu besloten om in het jaar dat de 
brancheorganisatie geen brede vakbeurs orga- 
niseert, ook voor EDA/engineering software een 
kleinschalige, laagdrempelige technologieshow 
te organiseren. 

Met de realisatie van deze eerste editie, de EDA 
Dag ’96, wordt dus een traject ingezet van elk 
jaar een activiteit waarin de leveranciers en ge- 
bruikers van elektronica ontwikkelsoftware el- 
kaar ontmoeten om de nieuwste produkten te 
zien en te analyseren en om ervaringen in het 
gebruik uit te wisselen. 


In deze eerste specifieke nationale EDA Dag 
staat niet alleen de technologie als zodanig cen- 
traal. Nadrukkelijk hebben de organisatoren er- 
voor gekozen in een strategisch middagseminar 
het investeringstraject en het rendement daarop 
ter discussie te stellen. 


De organisatie van deze EDA Dag en de vak- 
beurs, waarin volgend voorjaar weer een EDA/ 
engineering software zal zijn opgenomen, is in 
handen van het bureau van de Federatie Het 
Instrument, waarbij de leveranciers en een groot 
aantal gebruikers zijn aangesloten via hun 
brancheorganisatie voor Industriële elektronica 


drs. J.C. Groeneveld 

Het Instrument 

Nederlandse Branche organisatie voor 
Industriële elektronica 

Postbus 2099 

3800 CB Amersfoort 

Tel: 033-4657507 





Electronic Design Automation OK? 
en dan.... Met EDA tooling alleen 
redt je het niet 


1.1 Inleiding 


De ontwikkeltijd, kwaliteit en reproduceerbaar- 
heid van de electronica in produkten kan dras- 
tisch verbeterd worden door de designflow aan 
een grondige inspectie te onderwerpen. 


Vragen die men zichzelf kan stellen zijn: 
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Beheers ik het electronica-ontwerpproces? 

Is mij bekend wat de kosten van redesign zijn? 
Hoe vaak moeten wij ontwerpfouten debuggen? 
Hoeveel tijd kost dit? 

Is mij duidelijk wat de oorzaak van de fouten is? 
Ligt het aan het ontwerpen? 

Ligt het aan de specificatie? 

Voldoen de componenten in het testsysteem aan 


hun specs? 

Hoeveel tijd stoppen wij in het onderhouden van 
de ontwerpsystemen? 

Hoeveel tijd kost het onderhoud van de biblio- 
theken? 

Weet ik zeker dat bibliotheken of componenten 
niet op een andere wijze ter beschikking 
staan? 
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Specificatie (tekst) 
Formele Spec. 
VHDL/AHDL 
Schema 

Place PCB 
Route PCB 


Test 


Figuur 1. Een nadere uitwerking van het 
electronica ontwikkelproces. 


Kan ik goed voorspellen hoeveel tijd een ont- 
werp zal gaan kosten? 

Hoeveel uitval heeft de produktie? 

Is bekend wat de oorzaak is van de uitval? 

Hoeveel field service wordt veroorzaakt door 
ontwerpfouten en welk deel door 
componentenslijtage(MTBF)? 


1.2 Electronica- 
ontwikkelproces 


Op het electronica-ontwerpproces kan 
een metafoor worden loslaten door te 
kijken alsof het een produktiestraat be- 
treft: 


De grote lijnen zijn vaak: 
Idee -> Schema -> PCB layout -> Pro- 
dukt 


Een korte analyse van deze ontwikkel- 
straat leidt al snel naar een verdere uit- 
werking voor de verschillende techno- 
logieën. Er is geen universele ontwikkel- 
straat voor alle electronica-ontwerpen 
op te stellen. Een heel groot deel van 
de electronica-ontwerpen kan worden 
opgesplitst in de volgende hoofd- 
onderdelen (en daarmee dus ook de 
verschillende produktiestraten): 


Deze opsplitsing wordt in hoofdzaak ver- 
oorzaakt door de verschillende toegepaste tech- 
nologieën. 

De ontwikkelstraat moet natuurlijk ook worden 
afgestemd op het eindprodukt. Een ontwikkel- 
proces voor een pacemaker zal anders verlo- 
pen dan die voor een electronische lichtregel- 
aar. Bedenk eens welke invloed dit laatste heeft 
op de designflow! 


1.3 Design iteraties 


Het is zinvol om de ontwikkelstraat te bekijken 
vanuit het gezichtsveld dat een ontwikkelproces 
altijd bestaat uit correcties van het reeds uitge- 
voerde. 

De meest ideale produktiestraat is een stap voor 
stap proces waarbij nooit een stap terug wordt 
gedaan omdat alle stappen 100% goed zijn. Dit 
is in de electronica-ontwikkeling mogelijk! Er zijn 
bedrijven in Nederland die electronicaprodukten 
ontwerpen, produceren en afleveren zonder de 
electronica in het eindprodukt getest te hebben! 
Dit kan alleen door een uitermate strak voorge- 
schreven ontwerpproces. Bij de analyse van het 
ontwerpproces moet 

normaal gesproken terdege met iteraties in het 
proces rekening worden gehouden. Enkele ad- 
viezen om iteraties niet te laten uitmonden in 
irritaties: 
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Verify PCB 
System wirering 


Zorg voor een goede 


eenduidige specifica- 

odin sean e Systeem specificatie 
mogelijk tussentijdse e PCB design 

stappen door het toe- . 

passen van: e FPGA design 


Specificatie simulatie 


Functionele simulatie e ASIC design 

Timing verificatie r 
Board level simulatie e Analog System design 
Systeem simulatie e j 

Natuurlijk horen daar DSP design 

ook de testen bij. e etc. etc 


(Testen doe je op 
hardware, simuleren 
met software) 

Het electronica- 
ontwikkelproces (de 
produktiestraat) is 
verder sterk afhanke- 
lijk van de historie van ontwerpmethoden 
en gereedschappen die in uw bedrijf zijn 
toegepast. Het is slechts voor enkelen 
weggelegd de ontwikkelstraat regelmatig volle- 
dig te vernieuwen. 


1.4 Bibliotheken 


Het is zinvol nog een andere analogie met 
EDA(Electronic Design Automation) te trekken. 
Het voorbeeld dat ik wil gebruiken komt uit de 


electronica. 





Figuur 3. Naarmate design iteraties langer op 
zich laten wachten nemen irritaties toe. 


binnenhuis architectuur. Er zijn veel systemen 
om gebouwen met hun inrichting te tekenen. De 
kwaliteit en toepassing van deze software hangt 
niet alleen af van de inwerktijd en gebruikers- 
gemak. Een zeer belangrijk onderdeel is de bi- 
bliotheek van waaruit geput kan worden voor de 
inrichting: 

Hoe uitgebreid is deze bibliotheek? 

Bevatten de componenten alle noodzakelijke 
informatie zoals materiaal, kosten van het 
component, levertijd, leverancier, toleranties 
etc. etc.. 

Kan ik bibliotheken van andere pakketten ge- 
bruiken? 

Kan ik informatie er weer uithalen voor de pro- 
duktie of voor de kostprijsberekening? 


Bibliotheken zijn de basisgegevens voor het 
electronica-ontwerp. Het is zeer aan te bevelen 
de tijd die daar door uw mensen wordt ingestopt 
aan een nader onderzoek te onderwerpen: 
Worden componenten weleens dubbel aange- 
maakt? 
Zijn er afspraken over de notatiewijze? 
Is er een goede link tussen de ontwerpers en 


Figuur 4. Design iteraties voorkomen door 
simulatie en test. 


Figuur 2. Er zijn verschillende 
ontwikkelstraten voor de verschillende typen 





hun libraries en de personen die het systeem- 
ontwerp doen? Zit daar dubbel werk tussen? 
Weet u zeker dat al deze informatie niet op een 
andere wijze beschikbaar is? 
Wat gebeurt er met eigengemaakte symbolen, 
shapes en simulatiemodellen? 
Ik weet zeker dat hier aanmerkelijke kwaliteits- 
verbeteringen en kostprijsreduktie bij elk bedrijf 
te realiseren is. 


En enkele vragen op het gebied van produkt 

data management: 

En hoe staat het met het beheer van oude ont- 
werpen? 

En correcties daarop? 

Wie weet welke versies van de software waar 
bij horen en hoe ze terug te vinden zijn? 


OK, dit zijn veel kritische vragen. Maar geen 
reden voor ongerustheid. Er is geen enkel be- 
drijf dat al deze aspecten volledig onder con- 
trole heeft. Om deskundig advies te geven heeft 
TRANSFER Electronic Design Support een 
nieuwe activiteit in het leven geroepen die bo- 
venstaande aspecten samen met de ontwerper 
kan doornemen, adviseren en zelfs delen er- 
van kan uitvoeren voor hem. 


EDAServices Europe verbetert het electronica- 
ontwerpproces zonder direct aan nieuwe tools 
te denken. Ze verbetert door de bestaande 
ontwerpomgeving beter in te zetten. De belang- 
rijkste verbeteringen zijn aan te brengen op de 
volgende gebieden: 


1.5 Conclusies 


Een nadere kritische blik op vervolgacties op 
elk ontwerpproces leidt zeker tot: 

Betere voorspelbaarheid 

Betere reproduceerbaarheid 

Minder redesigns 

Kortere designflow 







Specificatie en simulatie 
Component Simulatie 
Timing verificatie 
Systeem simulatie 


Component test 


Systeem test 
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Figuur 5. De kosten voor het opsporen van 
een ontwerpfout in de verschillende fasen. Let 
daarbij vooral op de exponentiéle schaal! 


Te bereiken doelstellingen zijn: 
Snellere reactie op marktveranderingen 
Meer alternatieven voor uw klant 
Betere bereikbaarheid van het TQM 


Maar vooral: Denkt alleer gij doende zijt, en al 
doende denk dan nog. 


Ton Zengerink 
TRANSFER Electronic Design Support 


Bibliotheken: (Voorkomen dubbel werk, dubbele informatie, betere modellen en beter ont- 


werp) 


Generatie: Symbolen 


Simulatiemodellen analoog, digitaal, timing, EMC, Cross-talk 


Produkt data management: 
Componentenbeheer 
Projectdata beheer 
EDA tools: 
Advies (tools & organisatie) 
Interfacing Tools <-> EDA tools 


Tools <-> non EDA tools 


Customization Tools<-> Ontwerpers 
Tools <-> Technologie 


Tools <-> Documentatie 


(Efficiënter gebruik, betere informatie naar andere systemen) 





Ontwerpers (Beter gemotiveerd, betere communicatie, efficiënter gebruik mensen en 


middelen) 


Begeleiding = in house CAD support 

Systeem specificatie trainingen 

Communicatie voor technici trainingen 

Technologie trainingen 

High level design trainingen 

(Kosten-sharing, kortere inwerktijd, lagere initiële investeringen) 


Sharing 
Bibliotheken 
Ontwerpers 
Tools 


Auke Vleerstraat 4 
7521 PG Enschede 





053-4330336 
t.zengerink @transfer.nl 





Real time software engineering 


strategieen 


Inleiding 


Software is een niet meer te stuiten opmars begonnen bin- 
nen technische produkten. Een produkt of een systeem met 
enig vernuft herbergt al snel enkele manjaren software 
ontwikkeling. Sinds de jaren vijftig neemt software steeds 
meer functies over van traditionele disciplines als mecha- 
nica, elektronica en electrotechniek. Software soupeert 
tegenwoordig al snel veertig tot vijftig procent van een 
produktontwikkelbudget. De hoeveelheid geld uitgegeven 
aan de arbeidsintensieve software ontwikkeling groeit dan 
ook jaarlijks met gemiddeld 12%. Een ander belangrijk facet 
waar software steeds meer haar stempel op drukt is de 


‘time to market’. 


Helaas heeft de opmars van software ook haar 
schaduwzijde. Door de explosieve groei van de 
vraag en de toenemende belangrijkheid van 
software, heeft de software industrie te kampen 
met twee probleemgebieden: een achterblij- 
vende produktiviteit en een slechte kwaliteit. 
Software staat berucht om het overschrijden van 
kosten en tijdsplanningen, en het optreden van 
fouten en tekortkomingen. Ongemak, forse fi- 
nanciéle schade of zelfs slachtoffers zijn het 
gevolg wanneer software het op kritieke momen- 
ten laat afweten, of te laat wordt geleverd. 


Reeds in de jaren zestig hebben deskundigen 
de noodklok geluid. Zij voorspelden software een 
grote toekomst, maar waarschuwden tegelijker- 
tijd voor de grote gevaren van software. Als men 
er niet in zou slagen om grip te krijgen op de 
ontwikkeling van software, dan zou software de 
beperkende factor worden bij het gebruik van 
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informatietechnologie. In 1968 introduceerden 
zij de term ‘software engineering’ met als doel 
de bouw van software doelmatig, voorspelbaar 
en betrouwbaar te maken door beproefde 
ingenieursmethodieken toe te passen. 


Toch heeft het nog een kwart eeuw geduurd 
voordat de industrie wakker werd geschud. Van- 
daag de dag onderkennen steeds meer bedrij- 
ven de cruciale rol die software speelt bij de be- 
scherming van hun marktpositie. Men is bereid 
te investeren in een structurele verbetering van 
de ontwikkelwerkzaamheden. 

Dat niet eerder is gereageerd kan worden toe- 
geschreven aan het ontbreken van software- 
kennis en -inzicht op bijna alle management- 
lagen. Ook was geen sprake van een essen- 
tieel concurrentievoordeel omdat alle partijen 
met vergelijkbare problemen kampten. Verder 
was er een tekort aan know how en aan profes- 


sionele hulpmiddelen. Maar ook het kwaliteits- 
denken (ISO) en de zwaardere regelgevingen 
hebben hun steentje bijgedragen aan de be- 
wustwording. 


De oorzaak van de problemen waarmee de soft- 
ware industrie te kampen heeft ontspringen voor 
een groot deel uit wat genoemd mag worden de 
‘weaknesses’ van software ontwikkeling. 


2.2 Software ‘weaknesses’ 


We hebben te maken met een: 
Achterblijvende produktiviteit. 
Matige kwaliteit. 

Toenemende complexiteit. 


De interactie tussen produktiviteit, welke al vrij 
snel aan manuren en dus kosten is te koppe- 
len, en de verschillende software kwaliteits- 
aspecten (betrouwbaarheid, gebruikersgemak, 
portability, efficiency, etc.) is zeer complex. Zo 
ook de interacties tussen de verschillende 
kwaliteitsaspecten onderling. 

De produktiviteit kan geen pas houden met de 
snelle groei van het aantal LOC (Lines of Code) 
dat men wenst te ontwikkelen. Het uitbreiden 
van de capaciteit door meer mensen en de ver- 
hoging van de produktiviteit per medewerker 
hebben geen oplossing gebracht. 


Door het tekort aan capaciteit en de groeiende 
complexiteit neemt de kwaliteit af. Directe ge- 
volg: Software levert niet de verwachte voorde- 
len, leveringen worden vertraagd, verlies van 
resources aan re-work. 

Indirect gevolg: Verlies van resources aan extra 
onderhoud 
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Professionele software ontwikkeling verdient de 
aandacht van het top-management. Alleen be- 
drijven die tijdig en strategisch ‘durven’ te inves- 
teren in de verbetering van de software ontwik- 
keling, of de software ontwikkelprocessen, heb- 
ben in de toekomst in de vorm van software een 
uitstekend wapen erbij in de concurrentiestrijd. 


Voordat we ingaan op de kansen die ons wor- 
den geboden om software ontwikkeling te ver- 
beteren gaan we kort in op het software 
ontwikkelproces en haar omgevingsfactoren. 


2.3 Het software- 
ontwikkelproces 


Doel van het ontwikkelproces is het afleveren 
van een (deel)produkt, een werkend programma 
compleet met documentatie. Voor een dergelijk 
produkt afgeleverd kan worden moet een aan- 
tal activiteiten uitgevoerd worden. Startpunt voor 
deze activiteiten is het idee, dat voor een be- 
paald onderwerp een systeem gebouwd moet 
worden. Wil men vanuit dit meestal vage idee 
komen tot een werkend en gedocumenteerd pro- 
dukt, dan zal een ontwerpproces moeten wor- 
‘den doorlopen. Ontwerpen is een creatieve be- 
zigheid. Dat wil zeggen, dat tijdens het ont- 
werpproces iets tot stand komt dat er van te 
voren nog niet was. Ontwerpen is een proces, 
waarbij afwisselend analyse-stappen en syn- 
these-stappen worden gezet. 


In afbeelding 1 zijn de typische activiteiten die 


Abstract globaal 


ù 0 


Synthese 





yy 


Concreet detail 









Functioneel 
ontwerp 


Analyse 
& eisen 





Vaag Z 
Informeel <i 


Fig. 1 


aan het ontwikkelproces ten grondslag liggen, 
weergegeven. 


Omdat men in het begin van het ontwerpproces 
veel abstracter bezig is dan aan het einde, is 
het nemen van een ontwerpbeslissing in het 
begin veel moeilijker dan aan het einde. In de 
praktijk is de verdeling van tijd, geld en man- 








Technisch 
Ontwerp 


Fig. 3 
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kracht over te onderscheiden fasen van de ont- 
wikkeling van informatiesystemen hiermee ech- 
ter in tegenspraak. 


2.4 Verdeling van de 
inspanningen in het 
omgevingsmodel 


In afbeelding 2 is het software-ontwikkelproces 
gepositioneerd binnen een organisatie. Het is 
een praktische methode om inzicht te krijgen in 
de distributie van de totale bestedingen over de 
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afzonderlijke activiteiten waaruit een organisa- 
tie kan kiezen om de toegevoegde waarde aan 
hun produkten mee te geven. De waarden zo- 
als in dit schema vermeld komen voort uit on- 
derzoeken van Porter (Business School 
Harvard). 


Wat direct opvalt is dat 4/5 van alle besteding- 
en wordt 
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Configuration Management en Version Control. 
-Maar liefst 68% wordt besteed aan de techni- 
sche effort binnen het software ontwikkeltraject 
voor het transformeren van inputs naar een af- 
gerond produkt. 

Wat hier opvalt is vooral de post ‘rework’ dat maar 
liefst 30% van de totale resources vereist. 
Hieronder wordt verstaan: alle niet voorziene 
herstelwerkzaamheden omdat de specificaties, 
ontwerpen of code foutief zijn of verkeerd gein- 
terpreteerd of omdat er tussentijds een her- 
oriëntatie heeft plaatsgevonden. 


Een ander gebied dat enige aandacht verdient 
is in dit schema benoemd als service. Deze ac- 
tiviteit, ook wel onderhoud genoemd, neemt over 
de gehele lifecycle van een produkt 70% van 
de totale kosten in beslag. We hebben er in dit 
schema geen percentage aan toegevoegd om- 
dat de distributie van de kosten over de verschil- 
lende activiteiten in de onderhoudsfase nauwe- 
lijks afwijkt van de distributie van de weergege- 
ven ontwikkelkosten verdeling. 


Aan deze weergave van de verdeling van de in- 

spanningen kunnen we de navolgende gevolg- 

trekkingen verbinden: 

verbeteringen op het discipline niveau zijn van 
doorslaggevend belang 

vrijwel alle componenten zijn zeer arbeidsinten- 
sief. Uitstekende kansen dus voor geautomati- 
seerde hulpmiddelen om de activiteiten effi- 
ciënter en kapitaalintensiever te maken. Bo- 
vendien wordt de kwaliteit van ‘human 
resources’ en het management steeds be- 
langrijker. 


In de organisatie zoals weergegeven in afbeel- 
ding 2 zijn naast de verdeling van de inspannin- 
gen, drie controleniveaus te herkennen. Het dis- 
cipline-controleniveau, waar het software- 
ontwikkelproces plaatsvindt, het activiteiten- 
controleniveau, waar bijvoorbeeld project- 
management en Quality Assurance thuishoort, 
en het organisatie-controleniveau. In afbeelding 
3 worden deze controleniveaus in een hiérar- 
chische piramide weergegeven. 


2.5 Controleniveaus 


Discipline controle betreft alle activiteiten die te 
maken hebben met het vak Software Enginee- 
ring: de vaardigheid om software (technisch) te 
kunnen ontwikkelen en te onderhouden. (Zie ook 
fig. 3) Zou in het model bijvoorbeeld een me- 
chanisch ontwikkeltraject zijn opgenomen, dan 
zou enkel dit deel van het model er anders uit- 
zien. Op dit controleniveau gaat de aandacht uit 
naar de Software Development Environment 
(SDE), moderne SE-methoden en werkprocedu- 
res en opleidingen. 


Activiteiten controle betreft activiteiten gerela- 
teerd aan het feit dat een project wordt uitge- 
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voerd. Op dit controleniveau gaat de aandacht 
voornamelijk uit naar de invoer van project con- 
trole systemen zoals Project Management, 
Quality Assurance, Configuration Management 
en Change Control. 


Organisatie controle geeft de voorwaarden aan 
voor de organisatie om software projecten te 
kunnen uitvoeren. De organisatie gedraagt zich 
conform een gedefinieerde manier van werken. 
Deze komt tegemoet aan de behoefte van de 
organisatie om gewenste wijzigingen gecontro- 
leerd door te voeren. 


SPI (Software Proces Improvement, van het 
Software Engineering Institute) en SPICE (een 
Europese variant ontwikkeld bij ISO) zijn werk- 
methoden die moeten resulteren in een efficiënt 
software ontwikkelproces met de volgende ka- 
rakteristieken: 

Voorspelbaar, kosten budgettering en plannin- 
gen worden binnen de geboden marges gehaald 
en de eindprodukten voldoen aan de kwaliteits- 
eisen van de gebruikers. 


Ze vertegenwoordigen een stappenplan waar- 
bij per stap de stand van zaken in kaart wordt 
gebracht en welke verbeteringsacties men moet 
nemen (Key Proces Area’s) om naar het vol- 
gende hogere niveau te komen. 


Centraal is het onder controle krijgen van het 
proces en vervolgens het verbeteren van het 
softwareontwik 

kelproces. 


2.6 Benaderingswijzen 


We kunnen een onderscheid maken tussen twee 
gangbare benaderingswijzen om verbeteringen 
door te voeren: 


Top-Down 

Het investeren in SPI of soortgenoten is buiten- 
gewoon belangrijk. Maar deze veelal Top-Down 
gerichte benaderingen vergen veel tijd en veel 
geld. De tijd die SPI in beslag neemt brengt het 
gevaar met zich mee dat de motivatie afneemt 
en het initiatief uiteindelijk strandt. We moeten 
dan ook continu op zoek gaan naar onderdelen 
die snel resultaat opleveren. Dat is van door- 
slaggevend belang voor de motivatie van alle 
betrokkenen. 


Bottom-Up 

Heeft als nadeel dat initiatieven in de kiem wor- 
den gesmoord door het ontbreken van strategi- 
sche budgetten, beschikbaar gesteld door het 
top-management. Hierdoor blijven verbeteringen 
meestal beperkt tot individuele engineers of ‘ei- 
landjes’ in de organisatie. 


Een meer kansrijke benadering is een combi- 
natie van Top-down en Bottom-up: de werkne- 
mers op de drie controleniveaus hebben allen 
vanuit eigen taken, verantwoordelijkheden en 
bevoegdheden hun eisen en wensen. Bovendien 
worden alle niveaus vanuit de markt en de soft- 
ware engineering wetenschap gestuurd. De ei- 
sen en wensen van de verschillende niveaus 
dienen steeds dichter bij elkaar te worden ge- 
bracht waarbij de nadruk ligt op het discipline 
en activiteiten controleniveau. Onze belangrijk- 
ste gereedschappen hierbij zijn moderne 
softwaretechnieken en geautomatiseerde hulp- 
middelen. 


Welke kansen worden ons geboden om vanuit 
het discipline controleniveau, ook wel de Soft- 
ware Development Environment genoemd, ver- 
beteringen door te voeren ? Voor de identifica- 
tie en de toekenning van de prioriteiten aan 
verbeteringskansen kunnen we gebruik maken 
van ‘The value chain’-methode ontwikkeld door 
Porter en zijn associaties op Harvard. 

Vervolgens zullen we ingaan op de mogelijkhe- 
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den die beschikbaar zijn om verbeteringen aan 
te brengen in het software ontwikkelproces. 


2.7 Kansen voor verbetering 
2.7.1 Teamprestaties 


De effectiviteit van een team wordt voorname- 

lijk bepaald door de capaciteiten van het mana- 

gement en demogelijkheden om de werkzaam- 

heden te sturen en te controleren. Belangrijk 

hierbij zijn: 

- Duidelijke doelen voor, functie en taken van 
het team en ieder individu 

- Goede communicatie 

- Werkprocedures 

- Leereffect 


De sturing die aan het ontwikkelproces kan wor- 
den gegeven kunnen we afleiden van de eigen- 
schappen van het software ontwikkelproces. 
Deze eigenschappen zijn o.a.: 

- eenmalig karakter; 

- vernieuwende elementen; 

- duidelijk begin- en eindpunt; 

- beperkte middelen (t d, geld); 

- gericht op een of meer concrete resultaten; 

- verscheidene betrokken deskundigheden; 

- een geheel van onderscheidende activiteiten. 


Dit zijn eigenschappen die aanduiden dat de 
meest geschikte wijze van beheersing de 
projectvorm is. We zien dan ook dat het ontwik- 
kelen van software over het algemeen als pro- 
ject plaatsvindt. 


Sturing van het ontwikkelproces 

Als we de beheersvorm of de sturing die we aan 
projectmatig werken vergelijken met andere 
werkwijzen en hun eigenschappen dan kunnen 
we o.a. daarvan afleiden: 

Sleutelwoord hierbij is: Methoden. Het gebruik- 
maken van projectmanagement methoden die 


Werkwijze Kenmerken 
Ad hoc 


Projectmatig 


Sturing 
Methodisch 


Routinematig Procedureel 





aansluiten op onderliggende ontwikkel- 
methoden bieden ons de mogelijkheid het 
ontwikkelproces te sturen en te controleren. 


Onder methoden wordt verstaan: 

Voorschrift dat aangeeft wat, wanneer en 
waarom gedaan moet worden. Een methode 
geeft dus richtlijnen die aangeven welke stap- 
pen gedaan moeten worden om tot een bepaald 
doel te komen. Let op, er wordt aangegeven 
‘welke’ stappen gezet moeten worden. Op geen 
enkele wijze wordt aangegeven hee men deze 
stappen moet zetten. 


Wat we in dit overzicht ook zien zijn stromingen 
om van ad hoc richting procedureel werken te 
gaan. En als we ons voorstellen dat ontwikke- 
laars al de nodige weerstand bieden om me- 
thodisch te werken dan kunnen we ons voor- 
stellen dat de volgende stap nog een graadje 
moeilijker zal zijn. 


Voordelen van methodisch werken zijn: 

1. Betere communicatie tussen ontwikkelaars en 
gebruikers. Voorlopig blijft de meeste pro- 
grammatuur zo ingewikkeld dat zij nog door 
mensen moet worden ontwikkeld. Dan zijn 
goede communicatie en een gemeenschap- 
pelijke werkmethode cruciaal voor succes. 

2. Projectmatige sturing wordt mogelijk waardoor 
grip op de voortgang en de kwaliteit van het 
eindresultaat wordt verkregen. (Daardoor min- 
der rework, minder lines of code, minder on- 
derhoud) 

3. Biedt de mogelijkheid om na te gaan hoe het 


is gedaan en om de werkmethode te verbe- 
teren. 

4. Beperken unieke creaties. Het beperkt de 
mogelijkheid, zoals bij handmatig software 
ontwikkelen, dat men een unieke creatie krijgt 
waarvan vaak alleen de geniale ontwikkelaar 
ervan weet hoe het werkt. 

5. Kennis en ervaring niet bij een persoon maar 
bij de organisatie. 


Wel dienen methoden, of liever methode-syste- 
men, aan bepaalde eisen te voldoen om effec- 
tief ingezet te kunnen worden. 


Eisen gesteld aan methode-systemen: 

1. Afdekken gehele Life Cycle 

2. Voldoende Algemeen zijn om bij verschillende 
problemen toegepast te worden 

3. Voldoende Specifiek zijn om bij verschillende 
problemen efficiënt en doelgericht toegepast 
te worden 

4. Waar de ten grondslag liggende basis filoso- 
fieën zodanig op elkaar lijken dat tussen de 
softwareontwikkelfasen het denkproces niet 
hoeft te worden gewijzigd 

5. Door gereedschappen ondersteunt waarmee 
zoveel mogelijk handelingen worden geauto- 
matiseerd 

6. Algemeen geaccepteerd zijn. Voldoende er- 
varingen, literatuur en opleidingsfaciliteiten. 


Samenvattend: om de prestaties van het team 

te kunnen optimaliseren is het van belang dat 

er wordt gewerkt volgens een gedegen, en goed 

toepasbaar methode-systeem. Andere 

aandachtspunten hierbij zijn: 

- Werving, juiste mensen op de juiste plek, ze- 
ker de manager, verwijderen van ‘misfits’ 

- Faciliteiten 

- Management getraind in praktische manage- 
ment technieken 


2.7.2 Efficiency ver- 
hogen 


Improviserend Flexibele -lage kwaliteit 
‘Gebonden flexibiliteit’ - 
goede kwaliteit 

Star - hoge kwaliteit 


In elke stap van het ontwikkel- 
proces 


We hebben reeds geconstateerd dat 
software-ontwikkeling arbeidsinten- 
sief is en zich uitstekend leent voor het gebruik 
van tools. Tools zijn bij uitstek geschikt om bij 
arbeidsintensieve en vaak routinematige 
werkzaamheden te ondersteunen. Om tools in 
een ‘Integrated Computer Aided Software Engi- 
neering Environment echt effectief in te kunnen 
zetten dienen ze aan bepaalde eisen te voldoen. 


Eisen gesteld aan een Computer Aided Soft- 

ware Development Environment 

Algemeen 

1. Voldoen aan de eisen gesteld aan de metho- 
den-systemen binnen de SDE 

2. Een onderdeel van een geïntegreerde Soft- 
ware Engineering of Project Support Environ- 
ment 

3. Ondersteunen gedurende de gehele life cycle 

binnen alle ontwikkelfasen 

Integratie tussen de verschillende ontwikkel- 

fasen 

5. Ondersteunen van multi-user en multi-project 
behoeften 

6. Beschikken over een Centrale (project) 
Repository waarin alle ontwikkelgegevens 
centraal worden opgeslagen en beheerd 

7. Een uniforme user interface en editors voor 
resp. binnen alle tools 

8. Ondersteunen van meerdere computer- 
platformen en heterogene netwerken 

9. Voorzien van een Application Programmers 
Interface 

10. Ondersteuning Cliënt/Server applicatie ont- 
wikkeling door integratie GUI en Database 
ontwikkeling 

11. Gefaseerd invoeren van de tools 


en 
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12. Evolutionair pad richting OT. 


Technisch 

1. Uitgebreide consistentie checks en traceability 
links 

2. Ondersteuning van moderne process models, 
naast Waterval, evolutionair, incrementeel en 
Rapid prototyping modellen 

3. Ondersteunen van geavanceerde software- 
technieken (Information Hiding) 

4. Ondersteunen van reverse engineering facili- 
teiten om de code consistent te houden met 
het ontwerp 

5. Krachtige documentatiefaciliteiten. Koppeling 
tekstverwerkers en DTP hulpmiddelen 

6. On line help systeem 


Stappen elimineren 
Een optimale efficiency is het elimineren van 
stappen. Voorbeelden uit het verleden hiervan 
zijn assemblers en compilers. Meer recent zijn 
software standaard-checkers, quality assurance 
functies, en analyse en design consistentie- 
checkers. Of: design-generation vanuit analyse, 
code (code structure generation), reverse engi- 
neering, documentation functions. Ook hierbij 
zijn tools onmisbaar. Inmiddels gaat ook steeds 
‘meer aandacht uit naar de generatie van code 
vanuit specs. 


2.7.3 Elimineer ‘Rework’ 


De belangrijkste post afgeleid van de verdeling 
van de inspanningen. 30% van alle resources 
worden hieraan besteed. Over de hele lifecycle 
zal dit wel oplopen tot 50%. Dit omdat rework 
kan worden verminderd of geélimineerd door de 
kwaliteit van het ontwikkelwerk te verhogen. 


Front-end aids 

Computer aided requirement & design analyse 
tools kunnen rework inspanningen drastisch ver- 
minderen door betere visualisatie van software 
specificaties, meer formele en ‘slanke’ specifi- 
caties, geautomatiseerde consistency & com- 
pleteness checking en geautomatiseerde trace- 
ability tussen de verschillende softwareontwik- 
kelfasen. 


Door gebruik te maken van moderne software 
ontwikkeltechnieken of ‘bewezen ontwikkeltech- 


nieken’, kan rework 





worden voorkomen. 
Voorbeelden hier- 
van zijn: vroegtijdige 
verificatie en valida- 
tie, modulair ont- 


Infrastructure 


human resource management 


Management 











werp, top-down ont- 
wikkeling, gestruc- 
tureerd programme- 
ren, walk-throughs 
of inspections, en 
software quality 
standaards. Een 
aanzienlijke winst in 
de onderhoudsfase 
van software kan 
worden behaald 
door technieken als 
‘information hiding’ 
en ‘data- 
encapsulation’. 
Rapid Prototyping de organisatie. 
en Simulatie 
Specificatie gebaseerd op een slechte vertaling 
van de wensen en eisen van de klant veroorza- 
ken in de meeste gevallen het meeste rework. 
Moderne Rapid Prototyping en simulatietools 
kunnen deze situatie significant verbeteren. 


Moderne procesmodellen 

Het meest toegepaste procesmodel is nog 
steeds het ‘Waterfall’-model. Indien toegepast 
in combinatie met doortimmerde front-end 
validatie activiteiten, kan deze document ge- 
oriënteerde methode zeer effectief worden toe- 
gepast in de bestrijding van rework. Maar door 
de toenemende tijdsdruk en de onzekerheden 
in wat en hoe er ontwikkeld moet worden, wordt 
steeds vaker gebruik gemaakt van moderne 
procesmodellen 

zoals het Evolutionaire model, en het Spiraal of 
het incrementele model. 


Reduceren van het aantal Lines of Code 

De grootste verbetering om het aantal ‘Lines of 
Code’ te reduceren kan worden gerealiseerd 
door het aantal te ontwikkelen programma in- 
structies te verminderen. De twee belangrijkste 
opties worden geboden door: 

- simpelere - niet mooier dan functioneel - pro- 





QA, CM 


Ontwerp 


Implementatie 





Fig. 4 Een modern procesmodel gepositioneerd in de omgeving van 


dukten te bouwen. 
- hergebruik van bestaande software componen- 
ten. Eigen en ‘third party’ bibliotheekroutines. 


2.8 Conclusies 


Door gebruik te maken van moderne software- 
technieken en hulpmiddelen (op een kosten- 
effectieve manier) zijn kwaliteits- en produktivi- 
teitsverbetering mogelijk. Bovendien kan de 
complexiteit beter in de hand worden gehouden. 


De verbetering op het development niveau moet 
aansluiten op het Software Proces Improvement 


plan. 

Sleutelwoorden: 
SPI 
Methodisch werken 
I-CASE tool 


Moderne software technieken 


Carl Heskes 
Bergson Technology B.V. 
Tel: 040-2423414 





Visie op de aanschaf van ontwikkel 
software met het oog op Cost of 
Ownership en trends in de markt 


Inleiding 


Om te begrijpen wat ons als hardware ontwerpers allemaal 
overkomt en hoe we naar de toekomst toe ons beleid moe- 
ten bepalen is het verstandig om te kijken of we trends 
kunnen ontdekken. In de totale globalisering van de indus- 
trie kunnen we heel duideliljk zien dat zowel voor de hard- 
ware- als de software-fabrikanten het verkrijgen van een 
groot produktievolume hun belangrijkste doelstelling is. 


Aan de hardware kant kunnen we duidelijk zien, 
dat de silicon manufacturers zich storten op die 
produkten, die hun een enorm produktievolume 
kunnen brengen. Denk daarbij in eerste instan- 
tie aan geheugenchips, dan CPU's, special chips 
vanaf een common interface tot en met een 
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PowerFET of een diode. 


Ook de software bouwers gaan tegenwoordig 
voor het volume. In de operating system-markt 
zien we duidelijk een Microsoft Novell en een 
Sun Soft. Desktop tools, databases, CAD-sys- 


temen en de grafische industrie zijn volume- 
markten of volumeprodukten op zich. 


3.2 Desktop versus 
embedded 


Qua karakter van de applicatie zouden we een 
onderscheid kunnen maken tussen open sys- 
temen en gesloten systemen. Dezelfde verge- 
lijking is van toepassing of ligt parallel aan desk- 
top versus embedded. Simpel gezegd zou je 
kunnen stellen dat een open system voorzien 
kan worden van software update en een geslo- 
ten of embedded system niet. Gek genoeg heeft 
dit niet alleen gevolgen voor de software, zoals 
we hadden mogen verwachten, maar ook voor 
het hardware-ontwerp. 
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Voorbeelden van desktop of open systemen zijn: 
onze administratieve computers, de PC’s, de file 
servers, de telefooncentrales en andere. 
Typische gesloten of embedded systemen zijn: 
de CD-speler, een inktjet printer, de GSM tele- 
foon, de kopieermachine etc. 

Als we qua hardware architectuur kijken, valt op 
dat we in de desktop of open systemen een grote 
interne strijd rondom de CPU-standaard zien. 
Het mag duidelijk zijn dat middels het enorme 
PC quotum Intel in feite deze strijd voortdurend 
wint. Echter, we zien een standaard CPU, een 
standaard chipset daar om heen, komend tot 
een standaard hardware platform. 


In de embedded wereld zien we deze standaar- 
disatie minder. Van de grote bekende chips zijn 
vele embedded derivaten gemaakt. Vaak zijn die 
zogenaamde single chip-versies beschikbaar 
gekomen. Een single chip bevat -naast de CPU- 
kern- ook alle input en output interfacing. Ook 
de desktop en de open systemen lijken zich op 
dit moment te standaardiseren rondom de PCI- 
bus. Middels deze busstruktuur kan men zijn 
specifieke computer interfaces eenvoudig toe- 
voegen. In de embedded wereld zal PCI zeker 
zijn toepassing vinden. Hoewel we daar ook to- 
taal andere strukturen zien, zoals het gebruik 
van field-bussen, modulaire back plane-syste- 
men en local area networking als 
interconnectiestruktuur. 


3.3 De factor ‘Produktie- 


volume’ 

Het kiezen van de beste oplossing voor een 
bepaalde toepassing is afhankelijk, natuurlijk, 
van vele faktoren. Een essentiele faktor die mee- 
telt is het volume waarop de nieuwe produktie 
gerealiseerd gaat worden. Om het denken een- 
voudig te houden, kan het beste een 
logarythmische schaal gebruikt worden. Wordt 
het produkt slechts 1x geproduceerd, 10x, 100x, 
1.000x, 10.000x of 100.000x per jaar. Afhanke- 
lijk van dit produktievolume zullen we allerlei 
keuzes moeten maken t.a.v. het gebruik van 
speciale hardware en speciale software. Het zal 
duidelijk zijn dat in de lagere volumes het ge- 
bruik van “off the shelf’- produkten zowel aan 
hardware als software kant voordelig zullen zijn. 
Nadeel is hierbij dat het tamelijk moeilijk is om 
het produkt een eigen gezicht te geven. 

Als we het over EDA-tools hebben, dan zullen 
we ons moeten richten op de produktievolumes, 
ongeveer startend bij 50 stuks per jaar en eindi- 
gend in het zeer grote volume. 


Van groot belang is het dat gebruikers inmid- 
dels van een speciaal produkt een prestatie ver- 
wachten die vergeleken wordt met een volume- 
geproduceerd produkt. Omdat ‘ons produkt’ zich 
specifiek richt op een bepaald niche 
toepassingsgebied, verwacht men vaak zelfs 
nog een veel betere prestaties dan van het stan- 
daard produkt. 


3.4 Nieuwe technieken en 
kostenbeheersing 


Doordat het voor de chips-producenten van zo'n 
groot belang is om te gaan naar volume- pro- 
duktie, merken we dat wij onze produktie- 
technieken aan moeten passen aan: 

- surface mount PCB-technologie; 

- chip-behuizingen als TAB, BGA etc.; 

- beschikbaarheid van componenten; 

- levensduur en prijs. 


We zien steeds meer dat de interessante chips 
verpakt worden op een manier die uitermate 
geschikt is voor zeer hoge volume- 
produktietechnieken. In verband met de com- 
plexiteit van de chip en/of de kosten van ver- 
pakking besluit de toeleverancier vaak dat een 
oudere verpakkingstechnologie niet meer van 
toepassing is. Dit betekent dus voor het midden- 
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en klein-bedrijf dat zij gebruik moeten maken 
van moderne produktietechnologién. De meeste 
componenten leveren inmiddels veel hogere 
prestaties dan 10 of 20 jaar geleden. Vaak is dit 
bereikt door een grotere rekennauwkeurigheid, 
gecombineerd met een veel hogere klok- 
snelheid. Twee faktoren, die over het algemeen 
het ontwerp niet eenvoudiger maken. Om al deze 
steeds maar ingewikkelder wordende chips aan 
elkaar te kunnen koppelen, moet er ook steeds 
meer “glue logic” tussen. Gelukkig hebben onze 
volumejagers hier iets op bedacht in de vorm 
van de Field Programmable Gate Array. Deze 
zeer complexe, maar vrij program 

meerbare hardware bouwsteen zorgt ervoor dat 
we in weinig ruimte de ingewikkelde glue logic 
kunnen maken. Helaas hebben we een aantal 
extra ontwikkeltools nodig om dit dan ook wer- 
kelijk te kunnen doen. De algemene trend die je 
kan waarnemen voor het midden- en kleinbe- 
drijf en zelfs voor de grote bedrijven die produk- 
ten in kleinere series maken is dat de kosten 
t.b.v. al deze nieuwe technieken hoger uitvallen 
dan in het verleden. Het maken van een aantal 
prototypen SMD printen is aanzienlijk kostbaar- 
der dan een dubbelzijdig doorgemetalli 
seerde uitvoering. 


Het kopen en onderhouden van de FPGA 
ontwikkeltools kost zeker meer geld dan vroe- 
ger. En als we het nodig hebben voor een iets 
groter volume om een eigen chip te ontwikke- 
len, dan zijn de kosten nog aanzienlijk hoger. 
Daarnaast hebben we steeds meer en duurder 
gereed-schap nodig om de debugging, het me- 
ten en het testen uit te voeren. Eigenlijk zou dit 
alles pleiten om terug te keren tot het maken 
van de wat simpeler elektronica. Helaas heb- 
ben ze dat in het Verre Oosten ook al ontdekt. 
En door de lagere salarissen aldaar zullen we 
daarmee hier weinig kansen meer hebben. 


Om een goede kans op overleven te hebben en 
zeker geld te verdienen zullen we ons hier moe- 
ten bezighouden met up to date-technologie. We 
moeten moderne produktietechnieken toe- 
passen en dat alles tegen de laagst mogelijke 
kosten. Hetgeen weer betekent, dat we met zo 
weinig mogelijk personeel zoveel mogelijk moe- 
ten zien te maken. Wat we maken moet zo on- 
geveer eeuwig meegaan, van een uiterst hoge 
kwaliteit zijn en zeker morgen beschikbaar zijn. 
In een poging deze bijna onmogelijke doelen te 
bereiken, kunnen we de ontwerpers van de elek- 
tronica niet meer alleen laten. In hun ongelijke 
strijd met deze uitdaging moeten ze geholpen 
worden door de elektronische design tools. Mid- 
dels deze CAD-software wordt de ontwerper de 
nieuwe architect van het PCB. Naast het instal- 
leren van design tools is het van groot belang 
dat een kwaliteitssysteem op zijn plaats gebracht 
wordt. Belangrijk is hierbij, dat zowel aan de pro- 
cedure, het proces als ook aan de mensen ge- 
dacht wordt. Het eindresultaat van de combina- 
tie van de tools en het kwaliteitssysteem moet 
zijn dat de klant als allereerste en als allerbeste 
geholpen wordt. 


3.5 De functie van de design tools 

De elektronische design tools brengen hulpmid- 
delen om het ontwerp te modelleren en het ont- 
werp te simuleren. Als dit op enig abstractie- 
niveau is uitgevoerd, kan vervolgens het geheel 
op microniveau herhaald worden. 

Ten behoeve van de FPGA wordt een bijna ver- 
gelijkbaar soort modellering-, simulatie- en 
ontwerpsynthese uitgevoerd. Bij ASIC’s is dit- 
zelfde patroon opnieuw van toepassing, maar 
moeten we tenslotte ook nog testfaktoren ge- 
nereren. 

Ten behoeve van printed circuit boards hebben 
we tools nodig voor component placement, het 
sporenplan rooten, het genereren van produktie- 
bestanden en het eventueel analyseren van 
hoogfrequent en warmtegedrag. 

Tenslotte moet ons design getest worden en 


testfactorgeneratie is steeds vaker een onder- 
deel van de complete keten. 

Belangrijk is dat de toolset ervoor zorgt, dat al 
deze losse aktiviteiten een onderlinge samen- 
hang houden. Het beheersen van een complex 
ontwerp en het meerdere mensen laten 
samenwerken verschillende mensen aan één 
design stelt hoge eisen aan de consistentie van 
alle bovengenoemde aktiviteiten. 


3.6 Winst door designtools 


Kort samengevat zouden we kunnen stellen dat 
we voor veel meer geld aan tools ook veel meer 
kunnen dan 10 jaar terug. Helaas is het zo dat 
we met de huidige tools maar net mee kunnen 
voor wat betreft de markteisen, die aan de 
volumeprodukten gesteld worden. Met een 
gelijkgebleven designtijd van ongeveer drie tot 
negen maanden maken we inmiddels wel veel 
complexere produkten met een hogere snelheid 
en een lagere produktieprijs. Ondanks deze 
voordelen brengen de design tools ons zeker 
niet de hemel op aarde. We zullen het design 
nog steeds zelf moeten bedenken en we heb- 
ben steeds meer training nodig voor pas afge- 
studeerden. 


Eenmaal de design tools op hun plaats, bieden 
ze voor een langere tijd rust in de organisatie. 
Door het creëeren van een eigen componenten 
database en het hergebruik van eerder uitge- 
voerd deelontwerp kunnen we het nodige geld 
besparen in de toekomst. Mede door dit her- 
gebruik, maar ook door het algemene gedrag 
van de tools zelf maken we aanzienlijk minder 
fouten in onze designs dan vroeger. De toepas- 
sing van gestruktureerde ontwerptalen zoals 
VHDL helpen om de ontwerpdocumentatie op 
een aanzienlijk hoger plan te brengen. De over- 
dracht van een ontwerp is daarmee op een meer 
formele basis uit te voeren. Het uitvoeren van 
onderhoud aan reeds gemaakte ontwerpen is 
veel eenvoudiger. Het doorvoeren van kleine 
wijzigingen brengt vrijwel geen risico met zich 
mee omdat een volledige testomgeving reeds 
gemodelleerd is. Het gebruik van abstracte be 
schrijvingstalen, zoals VHDL, zorgt ervoor dat 
onze glue logic ontwerpen technologie-onafhan- 
kelijk worden. Niet dat dezelfde VHDL-source 
onmiddellijk gesynthetiseerd kan worden naar 
een andere componentfamilie, maar de over- 
gang is minder desastreus dan met tools die 
specifiek van speciale chipfabrikant zijn. 


Algemeen kunnen we stellen dat de rijpheid en 
volwassenheid van de ontwerpen en het daar- 
bij passende hergebruik de beste basis vormen 
voor het geld verdienen middels de design tools. 


Siebren de Vries 
Chess Engineering 
Tel: 023-5317351 
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Design Automatisering: geloof en 
werkelijkheid 


Inleiding 


Ter gelegenheid van de door het Platform EDA/Software- 
ontwikkeltools van Het Instrument georganiseerde EDA Dag 
1996, is aan de sectie Design Technology and Automation 
van Hollandse Signaalapparaten B.V. (Signaal), in Hengelo, 
gevraagd om haar visie op design-automatisering te geven. 


Het zou te ver gaan om in dit artikel alle aspec- 
ten m.b.t. design technologie (d.i. de kennis en 
kunde die nodig is om het ontwerpproces voor 
een bepaald produkt, als functie van een be- 
paalde engineering discipline, adequaat te on- 
dersteunen) en de bijbehorende automatisering, 
de revue te laten passeren. 


Deze tekst zal zich beperken tot een toelichting 
van de automatiseringsbehoefte voor de ontwik- 
keling van diverse elektronica produkten, gezien 
in het licht van de technische- en defensiemarkt 
specifieke beperkingen, waar een bedrijf als 
Signaal mee te maken heeft. Deze behoefte 
staat geenszins model voor de behoeften in het 
Midden en Klein Bedrijf. 


Naast de noodzaak voor het geloof in de toe- 
passing van automatisering, wordt ook ingegaan 
op een meér kwantitatieve benadering, die mede 
bij het nemen van investeringsbeslissingen 
wordt gebruikt. 


Besloten wordt met een aantal conclusies aan- 
gaande de objectivering van Cost of ownership 
en de ROI en met een aantal aanbevelingen, 
gezien vanuit de wensen van een eindgebruiker, 
om de kwaliteit van de door de EDA- 

industrie in het algemeen geleverde ondersteu- 
ning te verbeteren. 


4.2 Hollandse Signaal- 
apparaten: een introductie 


4.2.1 Het bedrijf 


De geschiedenis van Hollandse Signaal- 
apparaten B.V. gaat terug tot 1922. Het bedrijf 
hield zich in eerste instantie bezig met de ont- 
wikkeling en produktie van mechanische vuur- 
leidingssystemen. Via eigen onderzoek en ont- 
wikkeling heeft na de oorlog de ontwikkeling van 
de radar technologie en van de command en 
control en elektronische vuurleidingsystemen, 
een grote vlucht genomen. 


Er is zelfs een tijd geweest, dat Signaal haar 
eigen computerchips ontwierp, tesamen met de 
daarbij behorende instructiesets, operating sys- 
temen en software ontwikkelomgevingen. Daar 
is inmiddels verandering in gekomen door de 
beschikbaarheid van adequate processing tech- 
nologieën die commerciëel verkrijgbaar zijn. Ook 
tooling en met name software tooling voor de 
ondersteuning van de verschillende engineering 
processen wordt al geruime tijd niet meer bij 
Signaal zelf ontwikkeld. 


De elektronica ontwikkelingen bij Signaal om- 
vatten een breed scala aan subdisciplines, lo- 
pende van microgolf antenne componenten, 
microgolf IC's, samengestelde componenten op 
dunne film, hoogspannings en laagspannings 
analoge elektronica, digitale multilayer PCB's 
met daarop DSP’s en andere processoren, ana- 
loge- en gemengd analoge/digitale PCB's, 
ASIC’s , FPGA's en PLD’s, Interconnectie-tech- 
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nologie e.d. 


Voor een meerderheid van deze disciplines be- 
schikt Signaal over aansluitende eigen produk- 
tie- en montage processen en technieken. 


In 1990 is Signaal, dat daarvoor onder de 
Philips-vlag voer, overgenomen door het Franse 
elektronica concern Thomson. Signaal behoort 
nu tot de defensie-tak van dit bedrijf: Thomson- 
CSF. De positie van Signaal is die van een re- 
sultaat verantwoordelijke business unit, met een 
produktenpakket dat is toegesneden op de 
Naval Combat Systems markt. Daarnaast is Sig- 
naal “Centre of Excellence for Radar systems”. 


De tijd dat de defensie industrie één van de drij- 
vende krachten achter de verdere ontwikkeling 
van elektronische technologieën was, is voor- 
bij. Dit betekent dat deze tak van industrie bijna 
volledig afhankelijk is geworden van wat er op 
de civiele en commerciële markt verkrijgbaar is. 


Voor de situatie rondom ontwerptooling is dat 
enerzijds een voordeel: schaalvergroting leidt tot 
kostenreductie, maar anderzijds een nadeel: de 
meer geavanceerde en geintegreerde proces- 
sen worden niet of nauwelijks door de bulk van 
de markt ondersteund en de vraag is dus (te) 
klein. 


4.2.2 De produkten van 
Signaal 


Als “Centre of Excellence for Radar systems” is 
Signaal een van de belangrijkste ontwikkel- 
centra van radarsystemen binnen de defensie- 
poot van Thomson. Radar systemen voor de 
korte en de lange afstand, voor gebruik als 
waarschuwingsysteem en voor het doelvolgen, 
uitgevoerd in diverse technologieën en uitge- 
voerd als totaal systeem, d.w.z. antenne, zen- 
der, ontvanger en de signaal en dataprocessing, 
dit alles behoort tot het produktenpakket. Ook 
de combinaties met optische sensoren beho- 
ren daartoe. 


Daarnaast maakt Signaal vuurleidingssystemen. 
Dit zijn systemen waarin de sensoren gecombi- 
neerd worden met een stuk dreigingsevaluatie 
en resource-scheduling en met een interface 
naar één of meer afweersystemen. Die laasten 
kunnen bestaan uit iedere combinatie van ka- 
nonnen, raketten en torpedo’s, die overigens niet 
door Signaal zelf gemaakt en geleverd worden. 


Als derde onderdeel van het Naval Combat 
System, levert Signaal complete Command & 
Control systemen. Dit kunnen systemen zijn 
bestaande uit een simpele console met beperkte 
computerfaciliteiten, b.v. gecombineerd met een 
simpel richttoestel, tot volledig ingerichte com- 
mando centrales van fregatten en andere grote 
oppervlakte schepen. Ook kustverdedigingssys- 
temen behoren hier overigens toe. 


Op het civiele gebied ontplooit Signaal een aan- 
tal aktiviteiten in de sector Transport. Ook hier 


gaat het dan om command & control achtige 
systemen, gecombineerd met sensoren. 


4.2.3 De produkt- 
karakteristieken vertaald 
naar procesbeperkingen 


De markt van Signaal, die voor het grootste deel 
een export markt is, bestaat uit landen (overhe- 
den dus) met een marine. Het soort van pro- 
dukten kan het best worden omschreven als zeer 
complexe professionele systemen, die in alle 
gevallen bestaan uit elektronica, software en 
mechanica onderdelen, die op perfecte wijze 
moeten ‘passen’. De systemen worden geacht 
een hoge graad van betrouwbaarheid en 
inzetbaarheid te hebben en hebben een levens- 
duur van minimaal 20 jaar. In die tijd moeten ze 
overigens niet alleen onderhouden kunnen wor- 
den, maar ze moeten ook nog wijzigingen kun- 
nen ondergaan om ze aangepast te houden aan 
de veranderende omstandigheden en omgeving 
waarin ze gebruikt moeten worden. 


Het aantal gelijke of vergelijkbare systemen dat 
een bedrijf als Signaal afzet is echter bijzonder 
klein in vergelijking met bijvoorbeeld de 
automotive, telecommunicatie of computer 
markten. En van deze genoemde markten heeft 
alleen de automotive-markt te maken met rela- 
tief lange levensduren (telefooncentrales even 
buiten beschouwing gelaten). De ontwerp- en 
produktieprocessen van Signaal zijn daarom 
aan wat stringentere beperkingen onderworpen 
dan in andere industrieën misschien gebruike- 
lijk is. 


Om te beginnen moet het ontwerpproces ‘first- 
time-right’ zijn. Dat wil niet zeggen dat elke han- 
deling maar één keer mag worden verricht, maar 
dat de opeenvolging van handelingen, inclusief 
de voorziene iteraties, binnen de daarvoor ge- 
schatte tijd (en kosten) het gewenste produkt 
moet opleveren. 


Door de relatief kleine aantallen wordt er eigen- 
lijk voortdurend ‘nieuw’ ontworpen. Door de tijd 
echter, die er tussen het ontwerp van het ene 
radarsysteem en het andere zit, is de kans dat 
reeds eerder geïmplementeerde delen kunnen 
worden hergebruikt heel klein. In veel gevallen 
betekent de ontwikkeling van een nieuwe func- 
tie of een nieuw systeem, dat ook de te gebrui- 
ken implementatie-technologie weer gedeelte- 
lijk vernieuwd moet worden. En vernieuwing van 
de technologie brengt een procesverandering 
(en in sommige gevallen een methodologie-ver- 
andering) met zich mee. In de nasleep daarvan 
zijn er ook altijd andere tools nodig. 


De kostprijs van produkten is daarom in hoge 
mate NRE bepaald (d.i. Non Recurrent Enginee- 
ring kosten) en dat vereist dat de ontwerp- 
processen zo’n hoog mogelijke ‘toegevoegde 
waarde’ moeten opleveren. Dat kan alleen als 
ontwerpers zich kunnen concentreren op het 
vinden en verifiëren van de juiste oplossing en 
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dat zo snel mogelijk. Dit houdt in dat de ontwerp- 
omgeving een goed geintegreerde set van tools 
moet bevatten. De data- en de toolflow moeten 
zo transparant mogelijk worden gehouden. Ook 
aan de wijze waarop één en ander in het 
computernetwerk is geinstalleerd worden hoge 
eisen gesteld in termen van transparantie, be- 
schikbaarheid, onderhoudbaarheid, gebruikers- 
gemak, etc. 


Omdat produktontwikkelingen een relatief lange 
looptijd hebben (gemiddeld tussen de 0.5 en 2 
jaar), is ook de eis dat er twee volledige design- 
omgevingen naast elkaar tegelijkertijd kunnen 
draaien. Daarbij moeten verschillende mensen 
tegelijkertijd aan hetzelfde produkt kunnen wer- 
ken (bijvoorbeeld een ASIC of een board), zon- 
der elkaar in de haren te vliegen. Vanwege de 
eigen produktiemogelijkheden vraagt de CAD/ 
CAM interface extra aandacht. Maar die is zo 
ingericht dat zoveel mogelijk gebruik wordt ge- 
maakt van standaardformaten. 


Het feit dat produkten een lange levensduur 
hebben en gedurende die tijd toch wel wat bij- 
stellingen moeten ondergaan, eist dat de 
essentiele designinformatie wordt opgeslagen 
in tool-onafhankelijke formaten, liefst werelds- 
tandaarden (b.v. VHDL). 


4.3 Design Automatisering: 
het proces en de implemen- 
tatie 


4.3.1. Methodologie als 
uitgangspunt 

Het aspect “geloof” dat gebruikt is in de titel van 
dit verhaal, heeft te maken met de uitgangspun- 
ten die ten grondslag liggen aan de 
automatiseringsinspanningen bij Signaal. 


Het begint met het hebben van een “Design- 
methodologie”, d.i. een afspraak over een be- 
paalde werkwijze, die kan worden gebruikt om 
zowel de plannen als de resultaten te toetsen. 
Deze methodologie is niet heilig. Ze kent haar 
beperkingen en als deze beperkingen teveel 
negatieve invloed hebben op het uiteindelijke 
resultaat van het “Product Creation Process” 
(PCP) dan moet de methodologie worden bij- 
gesteld. Het PCP is overigens gedefinieerd als 
het Signaal-brede proces waarin kosten en in- 
spanningen worden omgezet in produkten en 
verdiensten. 


De Designmethodologie bij Signaal (welke in de 
afgelopen 3 jaar onderdeel is gaan uitmaken van 
een Thomson-CSF wijde werkwijze) kan als 
volgt in generieke termen worden omschreven: 


Gebruik een gefaseerde procesbeschrijving 
De fasering dient om een aantal bij elkaar ho- 
rende activiteiten te groeperen en om enige notie 
van ordening en sequentie aan te brengen. Het 
proces is de kapstok voor de beheersbaarheid 
van de inzet van resources en de kwaliteit van 
de output. 

Gebruik hierarchie 

Hierarchie is een middel waarmee overzicht kan 
worden gecreëerd en dus de beheersbaarheid 
van het geheel kan worden ondersteund. Het 
wordt gebruikt om van grote problemen kleinere 
problemen te maken, die elk afzonderlijk van een 
oplossing kunnen worden voorzien. 

Gebruik abstractie 

Abstractie is een middel om van een globale 
omschrijving van een oplossing, via het 
gecontroleerd toevoegen van beperkingen op 
het aantal mogelijke vrijheidsgraden van het 
voorgestelde model, te komen tot een implemen- 
tatie. Op de hogere niveau's is de beschrijving 
technologie-onafhankelijk, op de lagere niveau's 
wordt de keuze voor een bepaalde technologie 
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een extra beperking in het model van de be- 
schreven oplossing. 


De juiste modelering van het designproces is 
dan afhankelijk van de methodologie en natuur- 
lijk van de te gebruiken technologie. De werk- 
wijze voor het ontwikkelen van een PCB is im- 
mers anders dan die voor het ontwikkelen van 
een ASIC. 


Dat niet iedere werkwijze even gemakkelijk te 
ondersteunen is met de juiste tooling, kan ech- 
ter niet genegeerd worden. Dit betekent zeker 
niet dat de toolkeuze voorop staat. Sterker nog, 
deze komt altijd achteraan. Maar het aantal tools 
is beperkt en dus is de verkrijgbare functionali- 
teit wel degelijk een beperking om mee reke- 
ning te houden. 


4.3.2 De theorie 


esign-automatisering kan worden gedefinieerd 
als het vakgebied dat zich richt op het 
‘mechaniseren’ van handelingen, welke een 
onderdeel uit maken van ontwerpprocessen. 
Zoals met alle vormen van automatisering, le- 
vert deze mechanisatie alleen iets op als het 
proces goed bekend is en eenduidig beschre- 
ven kan worden. 


Bij Signaal wordt onderscheid gemaakt tussen 
de proces-beschrijving en de beschrijving van 
de ontwerp-flow. Het proces wordt gedefinieerd 
als de te onderscheiden sets van aktiviteiten, 
welke kunnen worden gegroepeerd als opeen- 
volgende stadia (ook wel fasen genoemd) in de 
ontwikkeling van een produkt. 

De designflow wordt gedefinieerd als de stroom 
van individuele aktiviteiten en de volgorde waarin 
ze moeten worden uitgevoerd. Eventuele 
iteraties tussen (meestal opeenvolgende) 
aktiviteiten zijn in de flow ook aangegeven. 


Het automatiseren in technische zin heeft dan 
voornamelijk te maken met het ondersteunen, 
d.m.v. software gereedschappen, van de indivi- 
duele aktiviteiten in de flow. De relatie met het 
proces wordt voornamelijk bewerkstelligd door 
eisen te stellen aan de input- en output forma- 
ten waarin de designdata wordt beschreven, met 
name op de fase-overgangen. 


Het automatiseren in administratieve zin heeft 
voornamelijk te maken met het proces zelf. De 
automatisering staat hier niet zo zeer ten dien- 
ste van de mechanisatie van een design- 
handeling, maar van de beheersbaarheid van 
het proces en de controle op de ysortgang. 


In theorie kan elk goed bekend proces geauto- 
matiseerd worden. De vraag of dat moet gebeu- 
ren, hangt af van de gevolgen van de automati- 
sering voor het proces. Het betreft dan niet zo- 
zeer de gevolgen in financiële zin, maar veel- 
eer de veranderingen die in het proces optre- 
den als gevolg van de automatisering. Deze 
veranderingen hebben o.a. te maken met een 
totaal andere tijdsverdeling over de verschillende 
fasen en aktiviteiten en de veranderingen in 
benodigde skills die wordt geintroduceerd. Ook 
kan het proces buiten de methodologie gera- 
ken. 


4.3.3 Enkele aspecten van 
de realiteit 


In de industriële praktijk is er altijd sprake van 
een groot aantal beperkende factoren die de 
keuze van de middelen en zelfs de keuze van 
het inzetten van dergelijke middelen, beinvloe- 
den. 


Om te beginnen is er een verschil tussen de 
academische benadering van het ontwerp- 
proces en de industriele werkelijkheid. In het 
eerste geval wordt het proces opgezet volgens 





een ideaal model en is de enige beperkende 
factor het ontwerp zelf. In het tweede geval ech- 
ter zijn er allerlei beperkingen, al voorafgaande 
aan de eerste designstap, die beperkingen op- 
leggen aan het proces en de implementatie er- 
van. Om er een paar te noemen: er is sprake 
van een beperkte componentkeuze, er zijn be- 
perkte computerresources, de vaardigheid en 
kennis van de uitvoerende ontwerper laat op 
diverse gebieden te wensen over, de tools be- 
vatten fouten en die zijn niet altijd overkomelijk 
(en soms niet eens vindbaar). 


Een tweede probleem wordt gevormd door de 
budgetbeperkingen. Deze gelden voor zowel de 
aanschaf in kwaliteit en kwantiteit van de te ge- 
bruiken tools, alsook voor de eindige designtijd 
die gegeven is. Hoewel de designinfrastructuur 
bij Signaal op het proces gericht is en zodanig 
ingericht dat ze voor een groot gedeelte de be- 
hoeften van veelsoortige produktontwikkelingen 
afdekt, moet voor ieder project opnieuw een stra- 
tegie worden bepaald om de bestaande moge- 
lijkheden zo optimaal mogelijk te benutten. 


De vaststelling dat de meerderheid van de elek- 
tronische ontwikkelingen NRE-gedreven is, ver- 
eist een ‘first-time-right’ benadering. Deze be- 
nadering vertaalt zich in het zo vroeg mogelijk 
en zo goed mogelijk elimineren van elk risiko 
dat een goede oplossing in de weg kan staan. 
Dit principe is ook van toepassing op de aan- 
schaf en inrichting van de designomgevingen 
zelf. Anderzijds leidt het tot eisen aan tooling en 
integreerbaarheid van tooling die zeker niet 
marktconform te noemen zijn en dus niet stan- 
daard verkrijgbaar. 


Weer een ander probleem vormt het behoud en 
toekomstig gebruik van de designdata. Deze 
data vormt de beschrijving van de oplossing en 
bevat dus alle toegevoegde waarde. Toegang op 
elk gewenst moment in de toekomst, tot de ken- 
nis (en dus de waarde) die in de oplossing ver- 
ankerd ligt, is van groot belang. Voor een pro- 
duktenpakket/markt combinatie zoals die van 
Signaal is hergebruik van kennis verreweg het 
meest van belang. Hergebruik van geimplemen- 
teerde functies en deelfuncties is, in deze tijd 
van snelle veranderingen inbijvoorbeeld het 
componenten-aanbod en de tooling, nauwelijks 
interessant. 


4.4 Cost of Ownership en 
ROI: enkele voorbeelden 


Met een tweetal voorbeeld berekeningen van 
Cost of Ownership en ROI zal geprobeerd wor- 
den het nut van deze berekeningen te bewijzen. 
Het laatste voorbeeld zal echter ook aantonen 
dat het ondoordacht accepteren van de 
berekenigen een gevaar in zich heeft. De ge- 
noemde bedragen geven alleen in relatieve zin 
de werkelijkheid weer; verder zijn ze gefingeerd. 


4.4.1 Voorbeeld 1: Introductie 
Boundary Scan Test 
Methode 


In 1994 ontstond er bij Signaal een grote be- 
hoefte om de bestaande printed circuit board 
(PCB) test methodologie te herzien. Hiervoor 
waren twee belangrijke technische argumenten 
te vinden: 


Het schrijven van test vectoren op de huidige 
manier, voor een volledig functionele test via 
board-connectors en teststekers, wordt steeds 
moeilijker en tijdrovender, terwijl de kwaliteit van 
de vectoren steeds moeilijker te controleren is. 
De verwachting is dat voor toekomstige PCB's 
geen test vectoren meer met de hand geschre- 
ven kunnen worden binnen een redelijke tijd en 
met een acceptabele kwaliteit. 
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Het gebruik van componenten met steeds klei- 
nere pitch noopt tot het gebruik van testpads. 
Deze testpads kosten ruimte op de PCB en kun- 
nen voor distorsie van signalen zorgen. De ver- 
wachting is dat voor testpads op toekomstige 
boards geen ruimte meer is en dat toekomstige 
high-speed ontwerpen te gevoelig worden voor 
distorsie door testpads. 


Ondanks de harde technische argumenten om 
Boundary Scan test methoden in te voeren is 
het van groot belang om een Cost of Ownership 
en ROI berekening te maken om de financiele 
consequenties boven water te halen. Dit zal de 
discussie over het wel of niet investeren duide- 
lijker maken en kan zelfs in het geval van een 
snelle ROI de discussie versnellen. 


De kosten kunnen gesplitst worden in Initiele 
Kosten, b.v. evaluatie, aanschaf, en introductie 
van hardware en software en Maintenance Kos- 
ten, b.v. de jaarlijke maintenance kosten van de 
software. De geschatte kosten, die apart zijn 
weergegeven voor twee afdelingen binnen Sig- 
naal, te weten de Ontwikkelafdeling en de afde- 
ling Produktie&Test, staan in tabel 1. 


Tabel 1: Kosten 
Ontwikkelafd. 


1995 42.000 
1996 e.v. 

1995 184.000 
1996 e.v. 


Produktie&Test 


De baten zijn geschat op basis van gegevens 
verstrekt door de ontwerpgroepen. Geschat zijn: 
het aantal nieuw te ontwikken PCB's met 
Boundary Scan in de komende jaren het aantal 
wijzigingen van PCB's met Boundary Scan in 
de komende jaren de besparing per nieuwe PCB 
in uren als gevolg van het gebruik van de 
Boundary Scan methode de besparing per ge- 
wijzigde PCB in uren als gevolg van het gebruik 
van de Boundary Scan methode. 


De baten, weer onderverdeeld naar de twee 
afdelingen Ontwikkeling en Produktie&Test 
staan in tabel 2. 


aantal PCB's 
1996 2 
1997 6 
1998 e.v. 13 

5 wijzigingen 
Produktie&Test 1996 2 
1997 6 
1998 e.v. 13 


Tabel 2: Baten 
Ontwikkelafd. 
80 
80 
50 
130 
130 
130 


Initiele kosten Initiele uren 
250 


470 


Baten per PCB (uren) 
80 


Bovengenoemde cijfers zijn in figuur 1 nog eens 
in een grafiek weergegeven. Het is direkt duide- 
lijk dat het omslagpunt ergens in 1998 ligt. Na 
het omslagpunt worden de baten hoger dan de 


tabel beschouwd. 


De kosten van het tool kunnen met de volgende 
formule worden weergegeven: 


Maanden 


Kosten = Aanschaf + Introductie + Yim -(Onderhoud + Ondersteuning -Uurloon) 


kosten. De investeringen verdienen zich dus bin- 
nen drie jaar terug. Omdat verwacht wordt dat 
de komende 5 tot 10 jaren de Boundary Scan 
testmethode niet wezenlijk zal veranderen, is dit 
een acceptabele terugverdien periode. 


4.4. Voorbeeld 2: Introductie 


Kwaliteitsanalyse tool 

De verificatiekwaliteit van VHDL modellen van 
ASIC’s, FPGA's, en PLD’s, hangt sterk af van 
de kwaliteit van de gebruikte testbench. Zo is 
het van belang om te weten of alle delen van 
een VHDL model wel worden gesimuleerd door 
een testbench. Het valt daarom te verwachten 


m=0 


Waarbij: 

Aanschaf = Aanschafprijs in guldens ( = FI. 
30.000,-) 

Introductie = Introductie kosten (opleiden gebrui- 
kers) ( = Fl 3000,- ) 

Onderhoud = Tool maintenance in guldens per 
maand ( = 10%/12 van de aanschafprijs ) 
Ondersteuning = Gebruikers ondersetuning in 

uren per maand ( = 2 uur per maand ) 
Uurloon = Loonkosten in guldens per uur ( = FI. 
110,-) 
Maanden= Gebruiksmaanden van de tool 


De baten kunnen met de volgende formule wor- 
den beschreven: 


Maanden 


Kosten = Aanschaf + Introductie + 2 m-(Onderhoud + Ondersteuning Uurloon) 


Maint.kosten 
4.200 

4.200 

18.400 
18.400 


Totaal (Hfl) 
71.200 
42.200 
249.400 
18.400 





dat een tool die de dekkingsgraad van een 
testbench voor een VHDL model kan geven, de 
kwaliteit van testbenches zal verhogen. Dit zal 
leiden tot kortere simulatie tijden, en dus een 
kortere design tijd, en minder re-designs als 
gevolg van niet opgemerkte design fouten. 

Voor tot aanschaf kan worden besloten zal eerst 
een kosten/baten analyse moeten worden ge- 
maakt om te bepalen of de kosten van het tool 
wel gedekt worden door de verwachte baten. 
Omdat dit een relatief nieuw automatiserings 
gebied is en de aangeboden tool nog volop in 
verandering is moet ook de terugverdien tijd niet 
te lang zijn. Een ROI van 1 jaar wordt als accep- 


Totaal (Hfl) 
16.000 
48.000 
104.000 
25.000 
26.000 


78.000 
169.000 
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Figuur 1: Kosten/Baten analyse voor Boundary Scan investeringen en verandering testmethodologie 
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m=0 


Waarbij: 

Gebruik= Gebruiks percentage van de tool. 

FPGAs = Aantal FPGAs per maand ( = 2 per 
maand ) 

Besparing= Besparing in uren per FPGA ( = 16 
uur ) 

Redesign = Aantal uren t.b.v. een redesign van 
een FPGA ( = 16 uur ) 

Foutkans = Percentage niet gevonden design 
fouten (= 10% ) 


Er van uitgaande dat het gebruik van de tool zal 
oplopen van 10% in de eerste maand naar 100% 
na 10 maanden, kan een kosten/baten analyse 
gemaakt worden. Het verloop van kosten en 
baten staan in een grafiek weergegeven in fi- 
guur 2. De ROI wordt bereikt na ongeveer 10 
maanden, hetgeen acceptabel is. 


Zou de tool echter Fl 60.000,- gulden hebben 
moeten kosten, dan ziet de Kosten/Baten aalyse 
eruit als in figuur 3. De ROI ligt nu veel te ver in 
de toekomst. 


Een gevaar van dit soort Kosten/Baten analy- 
ses is dat het resultaat zeer kan afhangen van 
één of enkele input parameters. Als voorbeeld 
van dit gevaar is in de bovenstaande analyses 
de besparing gehalveerd. Het resultaat is zicht- 
baar in figuur 4. De terugverdientijd is vedubbeld! 


4.5 Conclusies en 
aanbevelingen 


4.5.1 Cost of Ownership en 
ROI 


Met betrekking tot de Cost of Ownership moet 
worden gesteld dat deze bij Signaal wel dege- 
lijk een rol speelt. Er wordt niet in alles 
geinvesteerd en de automatiserings-infrastruc- 
tuur is primair proces gericht en niet project ge- 
richt. De beperking van het aantal toegestane 
componenten en technologieën en hergebruik 
van dezelfde methoden en technieken voor vele 
verschillende produkten in vele projecten, is 
noodzakelijk om de kosten i.v.m. investeringen, 
onderhoud en kennis, beheersbaar te houden. 


Dat betekent dat de aanschaf van middelen 
wordt bepaald aan de hand van verwachte of 
reeds noodzakelijk geachte verbeteringen in de 
ondersteuning van de ontwerpprocessen. Visie 
op en kennis van de EDA markt, van de eigen 
processen en van de gebruikte en te gebruiken 
technologieën, is daarbij onontbeerlijk. Een kwa- 
litatieve en een kwantitatieve ROI berekening, 
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Figuur 2: Kosten/Baten voor Kwaliteitsanalyse tool bij aanschafprijs van Fl. 30.000,- 
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Figuur 3: Kosten/Baten voor Kwaliteitsanalyse tool bij aanschafprijs is FI. 60.000,- 
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Figuur 4: Kosten/Baten voor Testbench Coverage Analyses tool bij Besparing = 8 uur per FPGA 


ter ondersteuning van de op een jaarlijks bijge- 
steld automatiseringsplan en technologieplan 
gebaseerde investeringsvoorstellen, is voor de 
meerderheid van de studies en investerings- 
voorstellen niet meer weg te denken uit het 
automatiseringsproces. 


Het gebruik van bepaalde technologieén is voor 
de Signaalprodukten van strategisch belang. 
Toch moeten er keuzen worden gemaakt. Het 
aantal te ontwerpen produkten of deelprodukten 
moet groot genoeg zijn om een redelijke kennis- 
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opbouw en belading van de aan te schaffen 
tooling te waarborgen. De kosten moeten terug- 
verdienbaar zijn, d.w.z. dat met nieuw aan te 
schaffen tooling een verbetering in het ontwerp- 
proces moet kunnen worden ondersteund (t.o.v. 
de bestaande situatie), die het mogelijk maakt 
binnen de economische levensduur van het tool 
de investeringskosten terug te verdienen. Ver- 
der moet het mogelijk zijn de kosten die gemoeid 
zijn met de introductie en het gebruik van het 
tool over de genoemde periode, tesamen met 
de gebruikskosten van alle andere tooling, bin- 


nen de grenzen van de toegestane R&D deel- 
budgetten te houden. 


Een heel belangrijke technische faktor bij de 
aanschaf van tooling is verder de mate waarin 
input- en output formaten van het tool zijn 
gestandaardiseerd. Het meest de voorkeur ver- 
dient het gebruik van internationale standaards. 
Indien niet voorhanden (of te prematuur) dan 
mag een de-facto standaard ook. De reden hier 
achter is simpel: in de data die met het tool ‘ver- 
werkt’ wordt zit de toegevoegde waarde van Sig- 
naal. Opgeslagen in de ‘proprietary’ database 
van de geachte tool-leverancier is de retentie- 
tijd hiervan nauwelijks meer dan 3 jaar. Voor pro- 
dukten met een levensduur van 20 jaar of meer 
is dit nauwelijks acceptabel. 


4.5.2 Een oefening in ge- 


meenschapszin 

In 1990 is er binnen Thomson-CSF een aantal 
grote synergie programma’s van start gegaan. 
Een daarvan richt zich op de design-technolo- 
gie t.b.v. elektronica ontwikkeling. De gedachte 
achter dit programma is eenvoudig: indien de 
meer dan 30 Thomson bedrijven die elektronica 
ontwikkelen een gemeenschappelijke werkwijze 
en min of meer dezelfde tooling gebruiken, dan 
kan de produktiviteit omhoog gaan en de inves- 
teringen omlaag. 


Eén van de principes hier achter is ‘economy of 
size’, d.w.z. dat je met 1000 ontwerpers sneller 
meer kennis kunt opbouwen en een betere 
marktpositie met scherpere prijzen kunt hante- 
ren, dan met 100. Ook blijf je als bedrijf beter 
bij: er is altijd wel een project dat de grens van 
het kunnen en de mogelijkheden verlegt, en de 
fouten hoeven maar één keer te worden ge- 
maakt. 


Het is natuurlijk niet gratis. Het vereist een in- 
spanning om het met elkaar over een aantal 
zaken eens te worden, het vereist dat je verant- 
woordelijkheid voor elkaar neemt (daar waar dat 
je eigen belangen niet schaadt) en het vereist 
dat je je niet blind staart op de problemen van 
vandaag maar nu gaat werken aan de oplos- 
sing voor die van morgen. In een bedrijf dat uit- 
eindelijk de resultaten van de business units voor 
100% consolideert en als één naar buiten 
brengt, is dat al simpel. Toch is het ook voor 
onafhankelijke bedrijven niet onmogelijk (Het 
Instrument is daar tenslotte zelf een voorbeeld 
van).Het model staat ter beschikking (en de ex- 
pertise van Signaal ook). 


4.5.3 Een optimalere onder- 
steuning: betalen voor ge- 
bruik 


Op dit moment heeft het begrip ‘floating’ licentie 
een tamelijk bekende klank in de EDA industrie. 
Toch is het nog niet zolang geleden (1992) dat 
het vragen naar deze mogelijkheid, om als klant 
een optimalere belading te bewerkstelligen, niet 
meer dan een verbaasde blik teweeg bracht. Ook 
nu nog wordt het door de tool-industrie veelal 
gezien als een mogelijkheid om de licentieprijs 
wat op te schroeven, dan een middel om sa- 
men met een uitgekiende produkt-samenstel- 
ling, een klant geld te besparen, dat in nieuwe 
functies geinvesteerd kan worden. 


Een voorstel (gedachten-experiment?) van Sig- 
naal, aan één van haar grotere leveranciers, om 
over te gaan op een puntensysteem, waarbij 
elke tool eenmaal gekocht wordt en er vervol- 
gens kan worden geinvesteerd in anonieme li- 
centie-punten. Het gebruik van een tool kost dan 
run-time een x aantal punten uit de punten-pool. 
Via een inflatie-mechanisme voor verbeterde 
releases en de minder hoogdrempelige uitnodi- 
ging om ook nieuwe functies in de ontwikkel- 
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DEMONSTRATIEDAGEN OP 21 MEI, 29 MEI EN 6 JUNI 


CADSTAR For Windows is het toonaangevende PCB ontwerp 


zijn nu ook beschikbaar in CADSTAR op een PC platform. 
pakket van Zuken-Redac, de marktleider* in PCB/MCM 


Kom kijken hoe EMC problemen in uw PCB ontwerp 
ontwerp software. daadwerkelijk worden opgelost op onze 
CADSTAR For Windows Platinum biedt een DEMONSTRATIEDAGEN 
ongelimiteerde en complete PCB 


ontwerp omgeving, inclusief schema 


tekenpakket, geavanceerde placement 


georganiseerd door Zuken-Redac en 

Koning en Hartman te Oosterhout. 
DINSDAG 21 MEI 

algoritmes en de unieke 

gridless auto-interactieve 


WOENSDAG 29 MEI en 
routing mogelijkheden 





DOWS.. : 
COMPATIBLE van Route Editor. 
32-Bit Application 


DONDERDAG 6 JUNI 





Bel Daphne Ploeg op onze ‘Demo 
CADSTAR For Windows kan vanaf nu Hotline’ voor uw gratis inschrijving 
op telefoonnummer 0499-392020, of schrijf u in per 
email: Daphne_Ploeg@redac.nl 


worden geleverd met de unieke Design Adviser en het EMC 
Rulebook. Deze software modules, die het resultaat zijn van 


een Europees onderzoeksproject, hebben hun waarde reeds Wij sturen u graag een programma en een routebeschrijving 


bewezen in de Unix ontwerp omgeving van Zuken-Redac en toe. 


ZU KEN 





REDAC 


World no.1 in PCB/MCM design 
De Ronde 13, 5683 CZ Best. Tel: 0499-392020 Fax: 0499-392902 


Windows” and Windows NT™ are trademarks of Microsoft Corporation. CADSTAR is a trademark of Zuken-Redac. 
* Zuken-Redac heeft een wereldwijd marktaandeel in PCB/MCM ontwerp software van 21.7% (Bron: Dataquest, September 1995) 
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omgeving op te nemen, wordt een voor beide 
partijen goed beheersbare en optimalere situa- 
tie bereikt. Natuurlijk werkt dit mechanisme be- 
ter voor middelgrote en groot gebruikers, maar 
voor klein-gebruikers zou het geen bijzondere 
nadelen hoeven te hebben. 


Een vergelijkbare situatie kan worden bereikt 
door in een bedrijf zoals Thomson de licenties 
te delen. Het feit dat het hier gaat om een groot 
aantal fysiek van elkaar verwijderde lokaties is 
nauwelijks bezwaarlijk als er sprake is van een 
intern elektronisch netwerk. De licenties worden 
centraal ingekocht en per maand ‘verhuurd’. Van- 
zelfsprekend is de bron-code (of executable) 
lokaal geinstalleerd en behoeft alleen de 
‘floating’ sleutel via het netwerk te worden ge- 
activeerd. Het moge duidelijk zijn dat dit alleen 
kan werken als er sprake is van een redelijke 
mate van gemeenschappelijke tooling, werkwij- 
zen en behoeften. 


4.5.4 Beschikbaarheid van 


adequate software tooling 
Nadat de EDA industrie zich een tijd lang heeft 
kunnen verheugen in ongebreidelde groei, is er 


sinds een aantal jaren een ombuiging zichtbaar. 
Verschillende bedrijven in deze tak van sport 
hebben al de nodige moeilijkheden achter de 
rug, al dan niet veroorzaakt door overnames. 
Maar ook deze bedrijven ondervinden de last 
van een steeds grotere veranderingssnelheid 
van de onderliggende technologieen, waarop 
geanticipeerd moet worden. 


Een duidelijke trend is nu reeds zichtbaar: 
defensiebedrijven en andere grote industrieën 
zullen hun krachten weer gaan bundelen en een 
deel van de voor hun procesondersteuning zo 
noodzakelijke ontwikkelingen weer in eigen be- 
heer gaan nemen. Thomson-CSF is hiervan een 
goed voorbeeld. In eerste instantie zal daarbij 
getracht worden de ontwikkeling bij de gereed- 
schap-fabrikant te sturen. In tweede instantie zal 
men zelf weer een deel van de ontwikkeling ter 
hand gaan nemen, al dan niet d.m.v. een strate- 
gische alliantie met een software fabrikant. Op 
gebieden als componentenbeheer, modellen en 
modellibraries, methodologie gerelateerde tools 
en stukken van de tool-infrastruktuur is dit al ge- 
realiseerd. 


Ook over het aanpakken van de relatief grote 


achterstand die de nu op de markt gebrachte 
tools hebben op de in de universiteitslaboratoria 
ontwikkelde algoritmen, wordt binnen de eind- 
gebruikers industrie opnieuw nagedacht. Ook 
deze industrie heeft immers toegang tot de uni- 
versiteiten en in tegenstelling tot de EDA indus- 
trie ligt het kantelpunt van de ROI berekening 
daar veel dichterbij. 


Het antwoord van de EDA industrie is er ook al: 
niet meer alleen de tooling, maar de dienstver- 
lening rondom het gehele ontwerpproces wordt 
‘produkt’. Het valt niet te ontkennen dat met de 
snelheid waarmee de wereld nu verandert, de 
EDA industrie een plaatsje dicht bij het vuur in- 
neemt en daarmee een lichte voorsprong kan 
opbouwen t.o.v. de eindgebruiker. Of ze nu al 
voldoende jokers in handen heeft, valt echter te 
betwijfelen. 


C. Nieuwenhuis 

E. Weening 

Hollandse Signaalapparaten B.V., 
Hengelo 

Tel: 074-2483288 





Erop of eronder: de Scantium, een 
ASIC doe het gemaakt heeft 


Scantech is een Nederlands bedrijf dat barcode scanners ontwikkelt, produceert en ver- 
koopt. Scantech is in 1987 gestart in Heerenveen en is sinds 1988 gevestigd in Amersfoort. 
In 1990 werd de RIS2010 geïntroduceerd, de eerste vaste barcode scanner in de wereld die 
gebruik maakt van een laserdiode. Tot dan toe waren er alleen laserscanners met een HeNe- 


laserbuis op de markt. 


Scantech levert zijn produkten aan PoS en com- 
puter partners over de hele wereld, die op hun 
beurt een totaal kassasysteem leveren aan eind- 
gebruikers. Scantech is de enige Europese fa- 
brikant van barcode scanners voor retail, ver- 
koopt de scanners wereldwijd en is in Europa 
nr. 2. De concurrentie komt uit de Verenigde Sta- 
ten. 


Het huidige produkten pakket bevat diverse soor- 
ten barcode scanners: 


MT60/MT80 _ :handscanner 

C2010 : retailscanner 

Hunter : presentation mode scanner 
ScanGuide : selfscanner/price checker 


Pollux : vertical scanner 


Castor : horizontal scanner 
Gemini : Catcher/Pitcher combination 
PolyLine : industrial linescanner 


In de R&D afdeling wordt onderzoek en ontwik- 
keling uitgevoerd aan nieuwe barcode scanners. 
Scantech is momenteel ca 90 man groot. Daar- 
van zijn ca 17 man werkzaam in R&D (elektro- 
nica/software en opto/mechanica). 


5.2 Hoe ziet een scanner 
eruit? 

Een scanner bestaat uit een scanpatroon ge- 
nerator, fotodetector, analoge voorversterker, di- 
gitale decoder en een microcontroller (zie blok- 
schema). Het scanning proces start met de ge- 
neratie van een laserstraal door een low-power 
laserdiode(670 nm golflengte). Met een aantal 
vaste spiegels en een ronddraaiend polygoon 
(bestaande uit een aantal opgedampte spiegels) 
wordt een lijnen patroon gemaakt. Als een pro- 
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dukt met een barcode in het scanvolume van 
de scanner komt, zal de laserstraal de barcode 
kruisen. Het laserlicht 
dat wordt diffuus ge- 
reflecteerd door de 
barcode, wordt opge- 
vangen via spiegels 
en een lens en wordt 


gefocusseerd op een Detector 


Deze decoders kunnen parallel gezet worden 
om meerdere barcode families te decoderen. 










Decoder 






fotodetector. Audio 
De opgewekte stroom and 
in de fotodetector visible 
wordt versterkt en ge- A signals 
filterd. De output van Se 
de analoge voorver- 
sterker gaat naar een 
hardware decoder, 

Host 


die de data real time 
analyseert. De micro- 
controller zorgt voor 
de besturing, postpro- 
cessing (berekening 
van het controlegetal) en de communicatie naar 
de kassa. 


5.3 Waarom is het Scantium 

project gestart? 

Er bestaan een aantal barcode families, die elk 

worden toegepast in specifieke markten. Meest 

bekend is de EAN8/EAN13 code, die in super- 

markten wordt gebruikt. TNO-TPD heeft in 1988 

voor Scantech 3 digitale decoder ASICs ontwor- 

pen: 

MC1: EAN/UPC codes (supermarkten) 

MC2: 2OF5/Interleaved/Matrix codes (indus- 
trie) 

MC3 : C39/Codabar (apotheken, bibliotheken) 





Echter vanuit de markt kwam een sterke be- 
hoefte naar C128/EAN128 codes. C128/ 
EAN128 kan de volledige ASCII karakterset 
bevatten. C128/EAN128 wordt toegepast in de- 
tailhandel en distributie, omverpakkingen met 
daarop bijvoorbeeld gewicht, inhoud en 
houdbaarheidsdatum gecodeerd. 


Het eerste idee was een MC4 te ontwerpen, die 
parallel aan een MC1/2/3 gezet kon worden. Dat 
kon relatief snel gerealiseerd worden, omdat het 
een voortzetting was van het MC1/2/3 concept. 


Al snel werd er gedacht aan verdere integratie: 


3 decoders simultaan in 1 ASIC: EAN/UPC, 
C128 en Wide/Narrow codes (C39, Codabar, 
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Beamsplitter 


Scan pattern generator 










Barcode 


20F5). 

Hiervoor waren een aantal redenen: 

Kostprijsverlaging (1 ASIC i.p.v. 2 of 3 parallel) 

Ruimtewinst op de pcb (scanners worden steeds 
kleiner) 

Mogelijkheid om enkele extra features te 
implementeren (fragment mode decoding) 

Bij/voor blijven op de concurrentie. 


Toen is besloten dit project zelf op te pakken, 
omdat tot dan toe de know how van deze voor 
Scantech cruciale technologie bij TNO-TPD zat. 
De behoefte ontstond om deze strategische ken- 
nis van het ontwerpen van decoders zelf op te 
bouwen. Er was echter binnen Scantech geen 
ervaring op het gebied van ASIC ontwerp en 
van decoder algoritmen. 


Eind ‘92 is een globale planning gemaakt door 
Scantech, i.s.m. TNO-TPD, en een schatting van 
de kosten. Later heeft de ASIC een werknaam 
gekregen: de Scantium. 


5.4 Hoe is de Scantium 
ontwikkeld? 


Begin ‘93 is er gestart met een specificatie in 
gewoon Nederlands (10 pagina’s). Daarna is er 
een C-model van de Scantium ontwikkeld. In- 
put was digitale data, zoals die ook uit de ana- 
loge voorversterker komt. Output was een string 
met de barcode. 


Er zijn 2 SUN sparc werkstations aangeschaft. 
Besloten is het ontwerp in VHDL te beschrijven, 
omdat deze taal een standaard is en de weg 
opent naar synthese. Door voor VHDL te kiezen 
dachten we minder afhankelijk te zijn van een 
specifieke ASIC-vendor. De VHDL bleek uitein- 
delijk toch vendor-specifieke constructies te be- 
vatten. 

VHDL vermindert het aantal fouten, doordat het 
ontwerp op een formele wijze beschreven wordt 
en niet in termen van implementatie. Bovendien 
kon al met het ontwerp gestart worden voordat 
de laatste onderhandelingen met ASIC-vendors 
waren afgesloten. De functionele VHDL simula- 
ties zijn gebruikt om de consistentie met het C- 
model aan te tonen. Als VHDL simulator is 
Vsystem van Model Technology gebruikt. 


Uit een lijst van 6 ASIC-vendors is uiteindelijk 
gekozen voor LSI LOGIC. Voor logische syn- 
these vanuit VHDL is gekozen voor Locam-V 
(Vsyn, OMA) van Philips ED&T. Philips zou oor- 
spronkelijk assisteren in het gate-level traject t/ 
m sign-off. Later in het project is door Scantech 
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Collector lens 


alsnog een SUN 
werkstation van 
Arcobel gehuurd met 
daarop het CMDE 
pakket van LSI 
LOGIC. Het CMDE 
pakket is gebruikt 
voor de gate level si- 
mulaties, static timing 
analysis, 
floorplanning en DRC. Het 
ontwerp is synchroon en 100 % 
scantestbaar gemaakt met gebruik- 
making van enkele trucs om de power 
dissipatie te beperken. Voor het automatisch 
genereren van de testpatronen is AMSAL van 
Philips ED&T gebruikt. 


5.5 Welke proces keuze? 


Tijdens het begin van het project is een schat- 

ting gemaakt van de benodigde hoeveelheid 

gates: 

logica : 30.000, ram : 16250, totaal : 46250 gate 
equivalent. 

Er is echter meer functionaliteit geïmplemen- 
teerd dan gepland. 


Uiteindelijk was het volgende nodig: 
logica :42250, ram : 18850, totaal : 61100 gate 
equivalent. 
De afmeting van de on-chip ram is: 512 x 8 bit 
(static, single port). 
Als ASIC-proces is LCA100k van LSI LOGIC 
gekozen. 


De redenen hiervoor waren: 

de prijs, support van Arcobel en het feit dat met 
dit proces de gewenste performance gehaald 
zou worden. 


5.6 Hoe was de project- 


structuur? 


Om de risico’s zoveel mogelijk te beperken is 

besloten tot een samenwerking tussen 

Scantech, TNO-TPD, Arcobel en Philips ED&T. 

De inbreng van de project partners was als volgt: 

- Scantech (2 man) : systeemkennis, bouw 
van C-model, VHDL entry/simulatie 

- TNO-TPD (1 man) : ervaring in ASIC de- 
sign, decodeeralgoritmen, VHDL entry/simu- 
latie 

- Philips ED&T (1 man) : ervaring in ASIC de- 
sign, support synthese, testbaarheid inbou- 
wen 

- Arcobel (1 man) : ervaring in ASIC de- 
sign, CMDE, sign-off, contact met LSI LOGIC 


Gedurende het project is er contact gehouden 
via vergaderingen, telefoon, fax en email. 


5.7 Welke problemen kwa- 


men naar boven? 

Het startpunt was: nieuwe (point) tools, nieuwe 
Unix werkstation omgeving en weinig ervaring. 
Het project heeft langer geduurd dan was ver- 
wacht. De start was eind ‘92 met de eerste specs 
op papier en in maart ‘95 waren we de eerste 
samples. De eerste planning - opgesteld door 
Scantech en TNO-TPD - ging uit van ca 1 jaar 
tot aan de synthese. Terugkijkend kan gezegd 
worden dat de complexiteit van het project in 
het begin onvoldoende is ingeschat. In het be- 
gin is door Arcobel een vuistregel genoemd van 
ca 200 gates/wk. Achteraf blijkt dit een realis- 
tisch getal te zijn. 

Ten behoeve van het synthese tool moest er 
nogal wat gewijzigd worden in de stijl van de 
VHDL. Vervolgens zijn er problemen geweest 
met de synthese library en het daarin 
geïmplementeerde delay model. Dit was van 
directe invloed op het totaal aantal gates. 


In de LCA100k technologie waren 2 die-sizes 





aangeboden. De grootste bleek echter niet in 
de aangeboden behuizing te passen. En we 
hadden de grootste wel nodig, aangezien het 
aantal gates groeide. Een grotere die-size had 
ook weer invloed op de synthese-library. 


Bijna aan het einde van het ontwerp-traject werd 
door Arcobel het LCA300k proces aangeboden 
vanwege prijs en dissipatie reductie. We zaten 
toen al dicht bij sign-off. Toch is besloten om voor 
de LCA300k technologie te gaan. 


Tot slot wilden we een powersimulatie doen om 
een schatting te doen van het gedissipeerde 
vermogen in de ASIC. Dit was mogelijk in de 
LCA100k technologie, maar dit werd helaas niet 
ondersteund in LCA300k. 


Ondanks deze problemen en de toenemende 
planningsdruk zijn er geen concessies gedaan 
aan de testbaarheid en de simulaties. 


5.8 Welke resultaten? 


Het was een race tegen de klok. Het ging erom: 
Scantium of scant ie um niet? Maar uit de 
samples bleek: first time right! De performance 
van de Scantium was een belangrijke factor in 
dit project. De performance kan direct afgeme- 
ten worden aan de maximum klokfrequentie: 

- Geschat in LCA100k technologie: 32 MHz 

- Geschat in LCA300k technologie: 40 MHz 

- Uiteindelijk in LCA300k : 48 MHz 


Er bleek een klein foutje in te zitten, wat een- 
voudig met 1 or poortje op het pcb op te lossen 
was. Geen reden voor een redesign dus! De 
Scantium wordt nu toegepast in alle nieuwe 
scanners (Hunter, Pollux, Castor, Gemini, 
PolyLine en Galaxyz. 


5.9 Conclusie 


Het Scantium project was van vitaal belang voor 
de concurrentie positie van Scantech. 

De investeringen waren groter dan oorspronke- 
lijk begroot (factor 1.7 x). 

De ontwikkeltijd bleek ook langer dan gepland. 
Het is belangrijk om in tijdplanningen de fac- 
tor 1.7 te introduceren om het enthousiasme 
te matchen met de realiteit. 

Een project van deze omvang is haalbaar voor 
een klein bedrijf als Scantech, mits 

- er een goed opleidingsniveau aanwezig is 
- er samengewerkt wordt met anderen. 

Er is ervaring opgebouwd in het bedrijf: VHDL, 
synchroon ontwerp, testbaarheid, planning, 
decodeeralgorithmen. 

De Scantium is ongeveer even duur als een 
MCA. 

De Scantium wordt nu toegepast in alle nieuwe 
scanners. 

Scantech gaat nu starten met de ontwikkeling 
van een analoge ASIC. 


Ronald Kemp 

Hoofd R&D 

Elektronica/software Scantech BV 
tel.: +31 - 33 - 4698400 

fax.: +31 - 33 - 4650615 

email.: kemp @scantech.nl 


RB Elektronica, uw 
partner in 
elektronicaland.. 
Slechts f27,50 voor zes 


proefnummers. 
Bel 0294-450460 
fax 0294-412782 


21 





THEMA: Electronic Design Automation 


Geintegreerde ontwikkelomgeving 
voor real-time software 


Inleiding 


Het bedrijfsproces dat zich bezighoudt met ontwikkeling en 
onderhoud van software wordt geconfronteerd met een 
toenemende hoeveelheid werk. Dit is een algemene 

trend binnen het vakgebied software engineering. 


Een aantal factoren is hier debet aan: 


- steeds meer functionaliteit wordt in software 
gerealiseerd, 

- software wordt complexer, 

- de life-cycle van produkten wordt korter, waar- 
door de productiviteit van software ontwik 

kelteams moet toenemen, 

- de hoeveelheid code waar onderhoud op ge- 
pleegd moet worden neemt toe. 


Voor het succes van een project zijn beheer- 
sing van de complexiteit, toename van de 
productiviteit en kwaliteitsborging essentieel. 
ProMod” is een CASE (Computer Aided Soft- 
ware Engineering)-tool dat is ontwikkeld om een 
bijdrage te leveren aan het behalen van deze 
doelstellingen. 


Globaal doorloopt een software ontwikkeltraject 
de fasen analyse, ontwerp en implementatie. 

ProMod®t®S ondersteunt algemeen geaccep- 
teerde methoden en technieken voor al deze 
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ontwikkelfasen. Behalve voor de individuele 
ontwikkelfasen beschikt ProMod®tS ook over 
tools om de overgangen tussen de afzonder 
lijke fasen te ondersteunen. Er kunnen 
traceability links tussen modellen uit verschil- 
lende ontwikkelfasen worden gelegd. Op deze 
manier wordt de gehele life-cycle, van analyse 
tot en met implementatie, afgedekt. Vanwege de 
traceability links ontstaat een samenhangend 
model, waarbinnen naar behoefte kan worden 
genavigeerd. Dit levert een krachtige bijdrage 
tijdens de onderhoudsfase waarin wijzigingen 
plaatsvinden in het technisch of functioneel ont- 
werp. Ook het overdragen van kennis over de 
applicatie aan anderen wordt op deze manier 
vereenvoudigd. 


Naast de hierboven beschreven mogelijkheden 
beschikt ProMod ®t®S over een aantal intrinsieke 
eigenschappen waardoor investeringen in de 
Software Development Environment gewaar- 
borgd blijven. Enkele van deze eigenschappen 
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zijn: 

- ondersteuning van alle gangbare 
platformen, 

- software engineers kunnen alleen 
of in een team ProMod?"¥S gebrui- 
ken (single-user/multi- 

user), 

- modulair opgebouwd, niet meer 
tools aanschaffen dan nodig, 

- ondersteuning van zowel gestruc- 
tureerde als object-georiënteerde Pe 














methoden en technieken, 

- openheid, gegevens uit de 
repository zijn toegankelijk en er 
kunnen vanuit ProMod?Ptvs 
koppelingen gelegd worden met 
externe tools en bestanden. 


Aan ProMod?'¥S, wat staat voor procesmodel, 

ligt het evolutionaire procesmodel ten grondslag. 
Dit betekent dat het doorlopen van een 
ontwikkeltraject niet op een voorge- 
schreven wijze hoeft te gebeuren. In een 
technische omgeving is deze manier 
van werken vaak wenselijk. Vanwege 
restricties op het gebied van tijd, geheu- 
gen en/of timing, wordt vaak in een 
vroeg stadium voor een (risico-)deel van 
de applicatie al een ontwerp- en 
implementatieslag uitgevoerd. Dit bete- 
kent dat voor delen van de applicatie 
het gehele traject is doorlopen, terwijl 
andere delen nog in de analysefase zijn. 
ProMod ®® js een tool dat is ontwikkeld 
voor en door de technische wereld en 
zodoende deze manier van werken on- 
dersteunt. 


In de volgende paragrafen wordt een 

globale beschrijving gegeven van en- 

kele ProMod®® tools. Vanwege de be- 

perkte ruimte worden enkel analyse- en 

ontwerptools behandeld en het tool om 
consistentie tussen de resulterende analyse- en 
ontwerpmodellen aan te brengen en te beheer- 
sen. 


1.2 De analyse- 
fase 


Een informatiesysteem kan 
op drie wijzen worden bena- 
derd: procesgeörienteerd, 
gedragsgeörienteerd en 
datageörienteerd. In het alge- 
meen mag gesteld worden 
dat in technische omgevingen 
de gedrags- en procesgeöri- 
enteerde benadering van toe- 
passing is (voor bestuurlijke 
informatiesystemen zijn dit de 
proces- en datageörienteerde 
benadering). Voor iedere be- 
nadering beschikt ProMod 
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PLUS over een apart tool. In onderstaande teke- 
ning zijn enkele diagrammen weergegeven van 
de verschillende analysetools. Omdat er tussen 
de verschillende modellen uit de analysefase 
overlap kan bestaan, wordt er met een centrale 
data dictionary gewerkt. 


Vanuit een diagram uit het ene model kunnen 
eenvoudig diagrammen uit de andere modellen 
worden benaderd.Op deze wijze kan er door het 
complete analysemodel worden genavigeerd. 
De ontwikkeling van de afzonderlijke modellen 
kan door verschillende mensen gelijktijdig ge- 
beuren. 


1.3 Het statisch ontwerp 


ProMod?'¥S beschikt over een tool om de stati- 
sche structuur van de software vast te leggen. 
Op het laagste niveau gebeurt dit d.m.v. function 
calling trees. Bij grotere projecten met veel func- 
ties leidt dit niet tot overzichtelijkheid. Om de 
overzichtelijkheid, en dus de grip, op de struc- 
tuur te vergroten heeft ProMod?'¥S hier een 
tweetal abstractiemechanismen aan toege- 
voegd, nl. modulen en subsystemen. Vertaald 
naar een ‘C’-omgeving kunnen modulen worden 
vergeleken met .c files, waarin functions zijn on- 
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dergebracht. Subsystemen zijn equivalent aan subdirectories, welke uit 
modulen bestaan. 


De nadruk bij het statisch ontwerp ligt op het vastleggen van de interfaces 
tussen componenten. Men moet hierbij denken aan functies, data, ty- 
pen en constanten. Binnen het statisch ontwerp worden mechanismen 
als information hiding en data encapsulation ondersteund. Door goed 
van deze mechanismen gebruik te maken kan hergebruik, één van de 
voordelen van de objectgeörienteerde aanpak, ook binnen de gestruc- 
tureerde manier van werken worden gerealiseerd. 


In de elektronica zijn begrippen als information hiding, black boxes en 
hergebruik al lange tijd gemeengoed. In onderstaande tekening wordt 
een parallel getrokken tussen componenten uit de elektronica en het 
ProMod?'¥s tool waarmee het statisch ontwerp wordt vastgelegd. 


1.4 Het dynamisch ontwerp 

Met het dynamisch ontwerp kunnen de run-time aspecten van een sys- 
teem worden vastgelegd. De code zoals deze in het statisch ontwerp is 
vastgelegd zal op een gegeven moment worden uitgevoerd. Het dyna- 
misch ontwerp geeft hier inzicht in. 


Binnen het dynamisch ontwerp worden taken (tasks) onderscheiden. 
Tasks stellen systeemdelen voor die parallel kunnen draaien. Tasks com- 
municeren met elkaar via messages en met de buitenwereld via events. 
Tasks kunnen worden gebruikt om processen in een multitasking-omge- 


ving weer te geven. De messages tussen de tasks stellen dan 


interprocescommunicatie mechanismen als messageboxes, queueus, 
pipes enz. voor. Een andere toepassing is dat tasks verschillende process- 
oren voorstellen. De tasks stellen dan bv. verschillende processorboards, 
PLC's, PC's enzovoorts voor. De messages stellen weer de communica- 
tie tussen de tasks voor (seriële lijn, VME-bus, ...). 


1.5 De consistentie tussen modellen 


Met het tool AutoTracer kunnen koppelingen worden gelegd tussen com- 
ponenten:uit de verschillende modellen. Op deze wijze kunnen 





ERD Mata Mick anar 
Se EAE 














Afhaaldina A WWI 


afhankelijkheden tussen componenten worden aangelegd, bewaakt en 
beheerd. Vanuit de AutoTracer kunnen de diverse modellen ook worden 
benaderd, waardoor het navigeren door de gehele applicatie mogelijk 
wordt. De configureerbare analyzer van ProMod®®S kan nagaan of er 
een volledige afdekking aanwezig is tussen componenten uit de ver- 
schillende ontwikkelfasen. 


Voorbeeld: In de onderhoudsfase kan worden nagegaan in welke mo- 
dule (statisch ontwerp) bepaalde functionaliteit (analyse) is gerealiseerd 
en op welke processor (dynamisch ontwerp) deze uitgevoerd wordt. 


Op onderstaande tekening zijn modellen uit de analysefase en de (sta- 


tische) ontwerpfase te zien. Niet zichtbaar zijn de modellen uit de (dyna- 
misch) ontwerpfase. 


Wim Jansen 
Bergson Technology BV 
Tel: 040-2423414 
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Embedded Development Life Cycle. 


Boor destecds neerd VELE ESE GERE ale 
vraag naar geavanceerde produkten wordt er steeds vaker 
micro-elektronica toegepast bij het ontwikkelen van nieuwe 
produkten. Vooral micro-controllers, met sterk geïntegreerde 
functionaliteit, vinden hun weg in vele applicaties. 


Traditioneel werden deze processoren in het verleden geprogrammeerd in ‘assembly’ doordat 


compilers te veel overhead genereerden en de 
daaruit voortvloeiende code bovendien vaak te 
traag was. Door de sterk verbeterde optimalisa- 
tie in de diverse hogere programmeer talen, 
zoals in eerste instantie PL/M en later C, stap- 
pen toch steeds meer bedrijven over naar een 
hogere programmeer taal. Vooral het gebruik van 
de taal C is over de laatste jaren sterk gestegen 
in populariteit en wordt nu niet alleen voor ont- 
wikkelingen voor MS-DOS en Unix (native) maar 
ook voor embedded applicaties gebruikt. Diverse 
onderzoeken tonen aan dat ook C++ in popula- 
riteit stijgt en bij ontwikkelingen voor 32- en 64- 
bits processoren reeds vaak wordt toegepast. 


Het grote voordeel van het ontwikkelen in C of 
C++ is dat reeds grote delen van de applicatie 
op het ontwikkelplatform zelf (PC of Unix) ge- 
test kunnen worden. Uiteindelijk moet de appli- 
catie natuurlijk met behulp van een cross- 
compiler naar de juiste microprocessor code 
vertaald en daarna getest worden. Een ander 
voordeel van het gebruik van C/C++ is dat een 
applicatie eventueel snel naar een andere mi- 
croprocessor architectuur overgezet kan wor- 
den. Vroeger ging men vaak uit van een pro- 
cessor die in voorgaande projecten werd toe- 
gepast. 


Vandaag de dag wordt er eerst gekeken naar 
de te ontwikkelen applicatie en wordt er daarna 
een keuze gemaakt voor de processor die hier 
het beste op aansluit. De chip-fabrikanten spe- 
len hier op in en introduceren processoren die 
voor een speciale verticale markt, b.v. automo- 
tive of telecommunicatie, bestemd zijn. Op deze 
manier wordt de investering die men heeft ge- 
daan in het schrijven van software in een hoge- 
re programmeertaal niet geheel te niet gedaan 
en kunnen grote delen hergebruikt worden. 


2.2 Debuggen, groei, naar 
VHDL-simulatie 


Ook het debuggen van embedded applicaties 
is over de jaren sterk veranderd. Vroeger werd 
vaak de applicatie in een Eprom geprogram- 
meerd en gekeken of deze naar behoren werkte. 
Later werden hier Eprom emulatoren voor ge- 
bruikt om het steeds terugkerende programme- 
ren van een Eprom te voorkomen. In de jaren 
80 kwamen de eerste universele ontwikkel- 
systemen van o.a. Hewlett-Packard, Tektronix en 
Philips op de markt. Deze systemen bestonden 
uit een computer en daaraan gekoppeld een in- 
circuit emulator waarmee het mogelijk was de 
processor tijdelijk te vervangen, de applicatie in 
RAM te laden en de applicatie te executeren. 


Door de hoge investerings kosten voor deze 
systemen ontstond er echter de behoefte aan 
eenvoudigere systemen die te koppelen waren 
aan de toen opkomende PC. Diverse fabrikan- 
ten brachten in-circuit emulators op de markt 
die te koppelen waren aan een willekeurige host 
zoals een PC. In het begin werd er nog op as- 
sembly niveau gedebugged maar naarmate de 
kwaliteit van de gegenereerde code van hogere 
programmeertalen groeide, werden de eerste 
Source level debuggers voor-o.a. PL/M en C 
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geïntroduceerd. 


Met deze debuggers was het mogelijk de appli- 
catie niet alleen op C, maar ook op assembly 
niveau te testen hierdoor werd het hele 
ontwikkelprocess sterk versneld. Traditioneel 
werden erin-circuit emulators gebruikt voor het 
debuggen van een applicatie maar door o.a. 
de vele derivaten die er van een bepaalde mi- 
cro-controller op de markt komen wordt het 
steeds moeilijker voor de fabrikanten van deze 
in-circuit emulators al deze derivaten te onder- 
steunen. Mede ook door de toenemende fre- 
quentie waarop deze processoren werken en 
de steeds kleiner wordende behuizing, is het 
voor fabrikanten van in-circuit emulators haast 
onmogelijk een oplossing tegen acceptabele 
prijzen te bieden. 


Omdat het ontwikkelen van software een steeds 
groter deel uitmaakt van het totale project, ont- 
staat er de behoefte in een vroeg stadium, als 
de hardware nog niet klaar is, de applicatie reeds 
te testen. Simulatoren brachten hier uitkomst en 
stelde een ontwikkelaar in staat reeds grote 
delen van de applicatie te testen. Helaas heeft 
een simulator het nadeel dat de applicatie 
slechts op een fractie van de uiteindelijke snel- 
heid functioneert en dat problemen die gerela- 
teerd zijn aan de hardware zich niet zullen open- 
baren. Zonodig moet ook de omgeving zoals |/ 
O en interrupts gesimuleerd worden. 


Een oplossing voor dit probleem is het gebrui- 
ken van een debugger op basis van het ROM 
monitor principe. Hierbij wordt een target moni- 
tor op het board geplaatst en vanaf de PC via 
een seriële poort de applicatie in RAM geladen. 
Op deze manier heeft men de volledige con- 
trole over het systeem en kan de applicatie real- 
time getest worden. Het nadeel van deze me- 
thode is dat de monitor enige resources gebruikt 
van het target board. In de praktijk wordt deze 
oplossing en die met een simulator dan ook ge- 
bruikt naast een in-circuit emulator die op dit 
punt geen beperkingen oplegt. Ook de chip-fa- 
brikanten hebben deze problemen zien aanko- 
men en hebben debug voorzieningen aange- 
bracht bij het ontwerp van de chip. Het meest 
bekend is hier de Back ground Debug Mode of 
kortweg BDM van Motorola. Deze eenvoudige 
Debug interface werd geïntroduceerd met het 
op de markt brengen van de nieuwe 68300 fa- 
milie en maakt het mogelijk via een speciale 
connector op het board de applicatie te kunnen 
laden, te steppen en breekpunten te kunnen 
zetten. Verder kan men via deze BDM interface 
de applicatie real-time executeren en het gedrag 
van de applicatie bekijken. Het enige nadeel van 
deze methode t.o.v. het toepassen van een in- 
circuit emulator is dat het geen “real-time trace” 
faciliteit heeft. Daarom werkt Motorola nu samen 
met enkele fabrikanten aan BDM+ waarbij dit 
wel mogelijk is. Ook andere chip-fabrikanten 
werken aan soortgelijke technieken. Zo wordt 
ook de JTAG interface, oorspronkelijk ontwikkeld 
voor boundary scan, vaak voor debug doelein- 
den “misbruikt”. 


Zeker bij high-end processoren zoals PowerPC 
wordt de snelheid en de “probing” een probleem 








en zijn ook fabrikanten van logic analyzers gaan 
zoeken naar een alternatieve oplossing. Door 
het mogelijk te maken een absolute file inclu- 
sief alle symbolische informatie te laden in een 
logic analyzer, kan er nu een referentie gelegd 
worden tussen de informatie die is opgesla- 
gen in het trace geheugen en de oorspronke- 
lijke source files. Op deze manier kan het trace 
geheugen nu in C worden weergegeven en kan 
men exacte informatie krijgen over de tijd die 
nodig is om b.v. een C statement of functie uit te 
voeren. Let wel dat ook deze oplossing zijn be- 
perking heeft bij o.a. micro-controllers en 
processoren met caching omdat niet alle infor- 
matie naar buiten komt. 


Recente ontwikkelingen geven aan dat er zelfs 
naar een nog hoger abstractie niveau wordt ge- 
keken. Hierbij wordt een source level debugger 
gekoppeld aan een VHDL simulator. Deze si- 
mulator kan de ontworpen chip op hardware ni- 
veau volledig simuleren. Op deze manier kan 
de gegenereerde code geëxecuteerd worden op 
een VHDL beschrijving van de nieuwe proces- 
sor.Hierdoor kan reeds in een vroeg stadium 
gekeken worden naar de performance van de 
chip en deze zonodig worden bijgesteld. Deze 
manier van ontwikkelen is door de hoge kosten 
echter niet voor iedereen weggelegd. 


2.2 Conclusie 


Het ontwikkelen van een embedded applicatie 
bestaat voor een steeds groter deel uit software. 
De tijd die nodig is voor het ontwikkelen van 
deze software kan sterk worden bekort door 
gebruik te maken van een hogere programmeer 
taal en de juiste hulpmiddelen voor het 
debuggen. Afhankelijk van uw situatie, de appli- 
catie en het beschikbare budget, is één van de 
besproken mogelijkheden voor u een oplossing. 


Kees van der Valk 
Tasking Software Nederland BV 
Tel: 033-4558584 


Neem nu dat voordelige 
proefabonnement en 
ontvang RB Elektronica 
het komende halfjaar 
voor slechts f 27,50. 
Er is ook een speciaal 


studentenabonnement 
en een speciaal 
bedrijfsabonnement 
voor medewerkers...... 
Bel 0294-450460 of 
Fax 0294-412782 voor 
meer informatie! !!!!! 


RB Elektronica, mei 1996 








THEMA: Electronic Design Automation 


OP ZEKER? VHDL 


DC/DC CONVERTERS e z 
E Design Solutions 


ENTRY 
SIMULATIE 
SYNTHESE 

CONSULTANCY 
TRAINING 


TRANSIOGIC 


























































































































































































































TRANSLOGIC BV 
Galvanistraat 14-1 Tel.: 0318 64 20 76 


AC J CIC ° d Postbus 620 Fax: 0318 64 17 61 
Bene eg 37, 4904 SJ Oosterho 6710 BP Ede info@translogic.nl 

















Uw soldeerdampen voor 99,97% gezuiverd 


Veel technici (her)kennen de geur van soldeerdamp. Soldeerdampen zijn schadelijk voor u: ze kunnen 

vervelende klachten en/of ziekten veroorzaken. Astma, een lopende neus, tranende ogen of een rauwe 

keel zijn hiervan sprekende voorbeelden uit de praktijk. 

De FE-soldeerbouten van Weller zuigen direct bij de soldeerstift de onstane dampen meteen weer op. 

Via een 4-trapsfilter in het Weller Zero-Smog-systeem wordt vervolgens de damp voor maar liefst | 
99,97% gezuiverd. Voorkom gezondheidsklachten. Bel Technical Tools voor de gratis catalogus en u kunt | 
morgen uw keuze al maken. 








Hoogstraat 62-64, 
3011 PT Rotterdam 
e Postbus 22031, 
Weller” soldeertechniek. 3003 DA Rotterdam 
Tel.: 010-4125697/4125874 
Een klasse beter. TECHNICAL TOOLS wv. Fax. 010-4115835 





RB Elektronica, mei 1996 25 








THEMA: Electronic Design Automation 





Software Quality Assurance voor 
embedded real-time software 


Introductie: het streven naar verbetering van de kwaliteit 


van software 


De stimulans voor het verbeteren van de systemen voor 
Software Quality Assurance heeft verschillende achtergron- 
den. De eindgebruikers van de software verwachten belang- 
rijke verbeteringen in de kwaliteit en de betrouwbaarheid 
van de produkten die ze inkopen. Kwaliteitsmanagers zoe- 
ken naar een hanteerbare referentie waartegen de kwaliteit 
van software kan worden afgezet en binnen de grotere be- 
drijven onderzoeken juridische afdelingen wat de gevolgen 
zijn van de produktaansprakelijkheid ten aanzien van fouten 
in de toegepaste software. Daarbij zien de R & D managers 
zich geconfronteerd met een streven naar een kortere ‘Time- 
To-Market’ waarbij de software een steeds groter deel van 


het uiteindelijke produkt vormt. 


Een groot aantal bedrijven heeft zich de afgelo- 
pen jaren ingespannen voor het opzetten van 
een gedefinieerd en gecontroleerd kwaliteits- 
systeem als ISO 9000. Ook de software ontwik- 
kelgroepen zullen hiervoor de juiste methoden, 
technieken en gereedschappen selecteren en 
implementeren om aan te kunnen tonen dat ook 
de software adequaat getest is en voldoet aan 
de standaarden van het bedrijf en de afnemers. 
In dit artikel willen we een aantal bestaande 
standaarden en methoden noe- 
men, en ingaan op de proble- 
men die hierbij specifiek spelen 
in een embedded omgeving 
waarin stringente eisen aan het 
real-time gedrag gesteld wor- 
den. Tevens zullen enkele sys- 
temen geïntroduceerd worden 
die hierbij hun diensten kunnen 
bewijzen. 


2 Het Software 
Life-Cycle Model. 


Het Software Life-Cycle Model 
beschrijft in een blokdiagram de 
verschillende stadia in het pro- 
ces dat gebruikt wordt voor het 
definiëren, produceren en on- 
derhouden van software. Alle 
kwaliteitsstandaarden voor soft- 
ware werken aan de hand van een model dat 
gebruikt wordt als basis voor het softwareproject, 
waarvan sommige werken met een specifiek life- 
cycle model. Hoewel de terminologie niet altijd 
gelijk is, beschouwen de meeste modellen 6 
fasen in de life-cycle van een software produkt. 
Voor referentie zijn hier de engelstalige termen 
aangehouden. 


User requirements: definitie van het project 

Software requirements: analyse van de aanpak 
van het project 

Architectural design: beschrijving van het ont- 
werp van het project (high-level) 

Production: gedetailleerd ontwerp en implemen- 
tatie 

Transfer: in gebruikname van de software 

Maintenance: after-sales service 


In het begin van de zeventiger jaren was het 
‘Waterval-model’ een van de eerste beschrijvin- 
gen van het ontwikkelproces dat algemeen werd 
gebruikt en vormde aldus de basis voor vele pro- 
cedures die bij de aanschaf van software door 
de overheid en industrie gehanteerd worden. Het 
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‘Waterval-model’ beschrijft de documenten die 
opgezet moeten worden ter afsluiting van elk 
van de ontwikkelfasen, elk document vormt hier- 
bij de basis voor de uitvoering van de opvol- 
gende fase, waarbij het model ook voorziet in 
de terugkoppeling van de bevindingen en be- 
nodigde modificaties naar de voorgaande fase. 
Deze documenten maken uiteindelijk bij de af- 
levering deel uit van het totale produkt 





Een voorbeeld van een Software Life-cycle mo- 
del: het ‘Waterval Model’ 


Vandaag de dag is men van mening dat dit mo- 
del een aantal serieuze tekortkomingen heeft. 
Vooral de nadruk op de overdracht van de do- 
cumenten (waarschijnlijk als gevolg van vraag 
hiernaar bij overheidsprojecten) wekten de sug- 
gestie van een filosofie waarbij het produkt ‘over 
de muur gegooid’ wordt naar een team van 
kwaliteitscontroleurs en er weinig terugkoppe- 
ling is naar voorgaande projectfasen. Hierdoor 
is het model ook minder geschikt voor projec- 
ten waarbij intensief gebruik gemaakt wordt van 
terugmeldingen door beta-testers. Het waterval- 
model is dan ook aangepast en verbeterd in een 
evolutionair ontwikkelmodel (waarbij het 
ontwikkelproces wordt herhaald op basis van 
informatie uit de praktijk), het ‘incremental-mo- 
del’ (waarbij de software in fasen wordt afgele- 
verd) en het transformatie-model (waarbij een 
proces voor de automatische regeneratie van 
de software wordt beschreven op basis van ope- 
rationele ervaringen). 


Het ‘Spiral Life-cycle model’ van Boehm is een 
voorbeeld van een moderne zienswijze t.o.v. de 
Software Life-cycle. Binnen dit model kunnen de 
eerder genoemde modellen als speciale ver- 
schijningsvormen worden opgenomen. [Ref 1]. 


Bij de keuze van de hulpmiddelen die zullen 
worden inzet voor Software Quality Assurance 
(S.Q.A.) is het belangrijk dat deze bijdragen aan 
een gecoördineerd en beheersbaar proces en 
inzetbaar zijn in zo veel moge- 
lijk fasen van het life-cycle-mo- 
del. 


3 Test- en docu- 
mentatie eisen in 
standaarden voor 
software. 


De ISO9000 kwaliteits- 
standaarden bieden een raam- 
werk voor het Kwaliteits- 
management systeem van een 
bedrijf, een infrastructuur 
waarin de organisatie kan vast- 
leggen hoe ze de diverse za- 
ken uitvoert. Hierbij wordt tot op 
het benodigde gedetailleerde 
nivo beschreven welke proce- 
dures gevolgd worden. Op Eu- 
ropees nivo is gekozen voor de ISO9000/ 
EN29000 standaarden, maar in dit artikel willen 
we ook kort ingaan op de standaarden die ge- 
hanteerd worden door de ESA en defensie. 


3.1 ISO9000 - Part 3. 


Gezien het tot nu toe relatief geringe gebruik 
van statistische kwaliteitscontrole bij de produk- 
tie van software (m.u.v. de overheid en bij mili- 
taire projecten) was er een apart document no- 
dig om aan te geven hoe de ISO9001 standaard 
voor kwaliteitsmanagementsystemen voor ont- 
wikkeling en produktie konden worden toege- 
past op software. Deel Drie van ISO9000, ge- 
publiceerd in juni 1991 beschrijft deze “Guideli- 
nes for the application of ISO9001 to the deve- 
lopment, supply and maintenance of software”. 
[Ref. 2] 


Bij het identificeren van de relevante aanbeve- 
lingen in deze belangrijke standaard moeten we 
waarschuwen tegen de selective interpretatie 
van welke standaard dan ook - alleen het 
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standaarddocument zelf is de geautoriseerde re- 
ferentie voor de implementatie. 


Echter, als het gaat om het uitvoeren van testen 
en performance-analyse is |SO9000-3 erg dui- 
delijk in de omschrijving van de uitgangspun- 
ten. De leverancier draagt alle verantwoordelijk- 
heid voor het vastleggen van de verificatie-ei- 
sen van de softwareprojecten en voor het be- 
schikbaar maken van de benodigde voorwaar- 
den om aan deze eisen te voldoen. Verificatie is 
in elke fase van het gekozen Life-cycle model 
nodig, vanaf het ontwerp tot en met de ‘after- 
sales’ ondersteuning. De testen moeten geba- 
seerd zijn op een nauwkeurig vastgelegd plan, 
de Test-Plan documenten. Dit Test-Plan moet alle 
fasen van de ontwikkelcyclus omvatten met een 
beschrijving van de test-cases en test-data, met 
een definitie van de verwachtte resultaten voor 
module-, integratie- en systeemtest bovendien 
een functionele- performancetest. Ook de test- 
omgeving, gereedschappen en testsoftware 
moeten in dit testplan zijn vastgelegd. 


Zoals in de meeste standaarden voor software- 
engineering en S.Q.A. wordt er veel aandacht 
besteed aan configuratiemanagement, een 
methode voor het beheren en beheersen van 
de versies van elke softwaremodule. ISO9000- 
3 adviseert dat configuratiemanagement wordt 
toegepast, niet alleen voor de software specifi- 
caties en bestanden, maar ook voor die delen 
van het ontwikkelsysteem die invioed hebben 
op de functionele en technische specificaties. 


(Een artikel dat verder op dit onderwerp ingaat 
vindt u onder [Ref 3].) 


3.2 European Space Agency 
(ESA) software enigineering 
standaard. 


Voor een meer gedetailleerde en veeleisende 
benadering van het management van software- 
ontwikkeling is het nuttig om de ‘ESA Software 
Engineering Standards issue 2’ te bekijken [Ref 
4] zoals gepubliceerd in februari 1991. Hoewel 
de bron van deze standaard erg ‘zwaar’ klinkt 
geldt dit niet voor de inhoud van het document. 
Het is gebaseerd op gezond verstand en erva- 
ring en is dan ook aan te raden voor een ieder 
die betrokken is bij softwarekwaliteit en een 
waardevolle referentie bij de opzet vanontwikkel- 
en S.Q.A.-procedures. Er zullen situaties zijn 
waarbij het volledige gebruik van deze standaard 
niet nodig is voor commerciéle of industriéle 
software, maar het gebruik van ‘hoe-je-het-zou- 
kunnen-doen’ en ‘wat-je-moet-doen’ elementen 
maakt het een erg bruikbaar document bij de 
voorbereiding op certificatie voor ISO9001 of 
DOD-STD-2167A. 


Zoals bij de meeste standaarden, vereist het 
ESA document dat een project wordt gepland 
in een aantal afzonderlijke fasen. Hoewel er hier- 
bij een Life-cycle model nodig is, wordt er niet 
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Het Life-Cycle Verificatie- en 
Validatie Model. 
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noodzakelijk van 
een bepaald 


model uitge- 

Acceptance Tests aan. Het vereist 
dat de ontwikke- 

ling en produktie 

System Tests woa seb 


seerd op drie 
principes uit de 
software engi- 
neering : Top- 
down ontwikke- 
ling, gestructu- 
reerd program- 
meren en gelijk- 
tijdige produktie 
en documenta- 
tie. Ter verduide- 
lijking van de ta- 
ken binnen een project stelt het document dat 
het projectmanagement verantwoordelijk is voor 
de selectie van de gebruikte methoden en ge- 
reedschappen en het opleggen van het gebruik 
hiervan. Het is de verantwoordelijkheid van 
S.Q.A. om er op toe te zien dat de juiste ge- 
reedschappen, technieken en methoden wor- 
den geselecteerd en toegepast. 


Integration Tests 


Net als in ISO9000-3 maakt de ESA specifica- 
tie duidelijk dat alle software onderdelen, inclu- 
sief de gebruikte ontwikkel- en testsystemen 
onder het configuratiemangement dienen te 
vallen. De testsoftware dient volgens de zelfde 
procedures en standaarden te worden ontwik- 
keld, gecontroleerd en gedocumenteerd. Dit is 
een basisvoorwaarde voor regressietesten. 


Het Software Verificatie en Validatie plan (SVV) 
is het basistestplan voor het proces en vereist 
dat het testplan vastlegt dat de softwaremodule 
of het systeem voldoet aan de verwachte eisen 
en dat de verschillen tussen de verwachte en 
werkelijke resultaten worden vastgelegd. 


3.3 Het Software Verificatie 
en Validatie plan (SVV) 


Uitgaande van kwalitatief hoogstaande software 
is het testen van het software produkt t.o.v. de 
specificaties van fundamenteel belang. De ESA 
standaard onderkent dat de testactiviteiten vaak 
het meest tijdrovende en dure onderdeel van 
het project zijn. Testen zou zowel verificatie als 
validatie moeten omvatten. Volgens het IEEE 
comité gelden de volgende definities : 


Verification : “the process of evaluating a system 
or component to determine whether the products 
of a given development phase satisfy the 
conditions imposed at the start of that phase” 


Validation: “the process of evaluating a system 
or component during or at the end of the 
development process to determine whether it 
satisfies specified requirements”. 


Eenvoudiger gezegd, meet verificatie het 
softwareprodukt t.o.v. de vastgelegde specifica- 
ties, terwijl validatie bevestigt of de software alle 
gevraagde functionaliteit correct uitvoert. 


In een effectief en efficiënt testproces moeten 
deze activiteiten plaats vinden in alle fasen van 
het ontwikkeltraject. Dit proces kan geïllustreerd 
worden met behulp van een diagram van het 
Software Verificatie en Validatie plan dat ook 
vaak het ‘V’-diagram wordt genoemd. 

Het Life-Cycle Verificatie- en Validatie Model. 


Deze representatie geeft ons enkele belangrijke 
richtlijnen voor de opzet van een gedetailleerd 
testplan en voor de keuze van de gereedschap- 
pen en methoden voor de implementatie van dit 
plan: 

Binnen elke fase van de Life-cycle moet het test- 
plan de activiteiten die zijn uitgevoerd verifië- 





ren met de eisen die in de voorafgaande fase 
gesteld zijn. 


Nadat een fase van het testpan is geïmplemen- 
teerd (unit, module of systeem) moeten de re- 
sultaten geverifieerd worden met de overeen- 
komstige ontwerp-fase. 


Bij de opzet van een efficiënt proces kan geen 
enkele fase in het testplan, noch een test- 
methode, gezien worden als belangrijker dan 
een ander. Elke fase draagt logischerwijze bij 
aan het verzekeren van de kwaliteit van het eind- 
produkt. 


3.4 DOD standaard 2167A 


Ter vergelijking hiermee willen we kort ingaan 
op de methoden en gereedschappen zoals die 
beschreven staan in een standaard voor mili- 
taire software die algemeen wordt toegepast, 
de US Department of Defense standard 2167A, 
voor “Defense System Software Development” 
[Ref. 5]. 


Hoewel strikt gebaseerd op een door documen- 
ten en contoles overheerste sequentiële aan- 
pak, staat de standaard een iteratieve of 
recursieve uitvoering toe van de belangrijkste 
fasen, waarin deze niet verschilt van de reeds 
besproken standaarden. De DOD standaard ver- 
eist het gebruik van systematische en goed- 
gedefinieerde software-ontwikkelmethoden voor 
alle belangrijke activiteiten waaronder integra- 
tie en testen, waarbij deze methoden weer moe- 
ten voldoen aan de formele documentatie en 
controles die bij deze standaard van toepassing 
zijn. 


De testelementen van het ontwikkelproces moe- 
ten beschreven zijn in het Software Test Plan, 
terwijl aan het eind van elke fase de met het 
eindprodukt meegeleverde documentatie een 
complete Software Test beschrijving of test- 
rapport moet bevatten van deze fase. 


De 2167A standaard beschrijft de criteria die 
van bijzonder belang zijn bij de selectie en het- 
gebruik van test- en S.Q.A. gereedschappen. De 
leverancier is verplicht in het testplan de limie- 
ten van de geleverde software te testen en vast 
te leggen. Hierbij is de noodzaak van 
Performance Analyse vastgelegd, waarbij niet 
alleen de prestatie-limieten waarbij getest is van 
belang zijn, maar ook de reservecapaciteit of 
‘headroom’ van het systeem. 


4 De ‘TickIT-Guide’ 


De “Guide to Software Quality Management 
construction and certification using EN29001”, 
[Ref. 6] zoals gepubliceerd door de U.K. Dep- 
artment of Trade and Industry is uiteraard geen 
standaard, maar wel een waardevolle referen- 
tie voor wat betreft de status van kwaliteits- 
managementsystemen in de softwareïndustrie. 
De ‘TickIT-Guide’ is een bruikbaar ‘recept’ voor 
de opzet van een kwaliteitmanagementsysteem 
ter voorbereiding op ISO9000 certificatie. 


4.1 Capability Maturity 
Model (CMM) 


In November 1986, is het Software Engineering 
Institute (SEI), met assistentie van de Mitre 
Corporation, begonnen met de ontwikkeling van 
een raamwerk dat door organisaties gebruikt 
kon worden ter verbetering van het software 
ontwikkelproces. In de praktijk werd dit raam- 
werk echter vaak gebruikt als model ter verbe- 
tering van het proces, waarna men besloot dit 
raamwerk hiertoe daadwerkelijk uit te breiden. 
Het resultaat was het Capability Maturity Model 
(CMM) Versie 1.0 dat later uitgebreid is tot Ver- 
sie 1.1 [Ref 11]. In dit document wordt het raam- 
werk beschreven, de structurele elementen er- 
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Continuously 
improving 
process 


Predictable 


Standard. 


consistent Defined 
process (3) 


Repeatable 
(2) 








Initial De vijf ‘Software Process 


Maturity niveaus. 


van en de definitie van de vijf nivo's. 

De volgende omschrijvingen karakteriseren 

deze vijf nivo's en de belangrijkste proces- 

wijzigingen : 

1) Initial: Het software proces kan omschreven 
worden als Ad-Hoc, soms zelf chaotisch. 
Slechts enkele processen zijn gedefinieerd en 
het succes is afhankelijk van individuele pres- 
taties. 

2) Repeatable: Door toepassing van proces- 
management worden kosten, tijdschema en 
functionaliteit bewaakt. Er is een procesdisi- 
pline bereikt waarin een vergelijkbaar project 
op dezelfde wijze uitgevoerd kan worden. 

3) Defined: Het softwareontwikkelproces voor 
wat betreft de management en engineering 
activiteiten is gedocumenteerd, gestandaar- 
diseerd en geïntegreerd in een standaard 
ontwikkelproces voor de organisatie. Alle pro- 
jecten maken gebruik van een bewaakt pro- 
ces voor de ontwikkeling en het onderhoud 
van de software. 

4) Managed: Gedetailleerde informatie van het 
softwareproces en softwarekwaliteit worden 
actief gemeten. Zowel het softwareproces en 
de produkten worden kwantitatief begrepen 
en bewaakt. 

5) Optimizing: Eris een continue programma ter 
verbetering van het softwareproces door te- 
rugkoppeling van ervaringen en de invoering 
van nieuwe technologiën. 


Het CMM wordt tegenwoordig steeds meer toe- 
gepast door organisaties als referentie voor waar 
men is en waar men naar toe wil aangaande de 
kwaliteit van het software ontwikkelproces. Voor 
meer informatie en een vergelijking met ISO ver- 
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handle commands * 


GetNextCommand (&cCommand, &sData); 








wijzen we graag naar het Soft- 
ware Engineering Research 
Centre in Utrecht of het Soft- 
ware Engineering Institute in 
de U.S.A. Door het SERC is 
een aantal voorlichtingsbij- 
eenkomsten georganiseerd, 
die naast het CMM ook ingaan 
op ESPITI (European Soft- 
ware Process Improvement 
Training Initiative) en SPICE 
(Software Process Improve- 
ment and Capability dEtermi- 
nation). 


4.3 Het belang 
van Software 
Quality 
Assurance voor 
embedded soft- 
ware. 


Er zijn in de loop der jaren steeds meer gereed- 
schappen ontwikkeld die behulpzaam zijn bij 
Software Quality Assurance. Sommige hiervan 
bestaan al jaren, andere zijn net in de markt of 
nog in ontwikkeling. Uiteraard kunnen we bin- 
nen het ontwikkelproces voor embedded soft- 
ware direct gebruik maken van een groot aantal 
gereedschappen die ook voor de ontwikkeling 
van ‘host-based’ software ingezet worden. Denk 
hierbij aan CASE (Computer Aided Software En- 
gineering) omgevingen, waarbij al dan niet ge- 
bruik gemaakt wordt van een formele taal (bij- 
voorbeeld SDL) en de versie-controle systemen. 
Hoewel door de aard van embedded software 
(of firmware) S.Q.A. hier minstens zo belangrijk 
is, zo niet belangrijker, valt er op dit gebied nog 
veel te doen. Door het ontbreken van specifieke 
oplossingen worden er vaak nog ‘klassieke’ ge- 
reedschappen als Logic analyzers en In-Circuit 
Emulatoren ingezet voor taken waarvoor ze ei- 
genlijk niet geschikt zijn. 







Optmizing 
(5) 


Een symbolische 
testroutine voor de 


In tegenstelling tot host-software spelen er bij 
embedded software een groot aantal harde ei- 
sen ten aanzien van de responsetijd en het 
geheugengebruik. Het is bij een administratieve 
toepassing geen enkel probleem als de software 
iets trager reageert dan volgens de specifica- 
ties gewenst is. Dit is hinderlijk maar zeker niet 
desastreus, de gevolgen hiervan kunnen een- 
voudig opgevangen worden. Bij een embedded 
toepassing, bijvoorbeeld een elektronische ont- 
steking, mag echter een meting NOOIT gemist 
worden of we lopen de kans dat het systeem 
faalt in het functioneren. Zo is er een groot aan- 
tal voorbeelden op te noemen waarbij het sys- 
teem volledig deterministisch moet reageren op 
bepaalde stimuli. Voor het geheugengebruik 
geldt iets soortgelijks. 


Bij een host-systeem is er vaak reserve-geheu- 
gen aanwezig in de vorm van ‘swap-space’ op 
een harddisk o.i.d. Bij een embedded Real-Time 
toepassing is het vaak om economische rede- 
nen al belangrijk het beschikbare werkgeheu- 
gen zoveel mogelijk te reduceren, het ‘overlo- 
pen’ naar eventueel beschikbaar back-up geheu- 
gen is niet mogelijk of in elk geval te traag ten 
aanzien van de gestelde real-time specificaties. 
Het gevolg zal zijn dat het systeem niet aan de 
specificaties voldoet of, waarschijnlijker nog, 
onderuit gaat. Het falen van een embedded sys- 
teem heeft in de regel ernstiger gevolgen dan 
bij een host-systeem. Het is ronduit slecht voor 
het imago (denk aan een telefooncentrale) of 
heeft zelfs levensbedreigende (medische, mili- 
taire, luchtvaart-toepassingen) gevolgen. Deze 
twee gevolgen hebben gemeen dat ze erg veel 
kosten met zich mee brengen. 


Een andere, nog ondergewaardeerde, reden 
voor S.Q.A. bij embedded systemen is het feit 
dat het vaak heel moeilijk is om bij de firmware 
(embedded software) een nieuwe versie te in- 
stalleren. Stel dat men als fabrikant 100.000 te- 
levisietoestellen of GSM-telefoons moet 
‘upgraden’. Ervaringen in de autoindustrie heb- 
ben geleerd dat hiermee vele miljoenen gemoeid 
kunnen zijn, nog afgezien van de schade aan 
het imago en de juridische aspecten. 


TIO II IORI ORI I I I II ITI OI I AKK A hk Akke IAI IA IH 


;* File : Test Macrolanguage File for PACKET.C * 


Ashling in-circuit ;* Ver : 1.3.7 i 
emulator metde Test- ;* 11:35 December 14 1991 z 
Macrotaal. : FEF IRI IIE KKK IEEE KE IFES HIKE IA IAA AA IK 
declare ; Declare the following local variables 
LOCAL %no_of_steps 
Pathfinder Source-level | enddeclare ; All variables declared 
debugger voor de CTS emulator echo on 


van Ashling Microsystems. 





/autokey:\ALT-F\lpacket.cso\E\’ ; Load the program-under-test 


/autokey:’\ALT-D\H’ 
res d ; Reset the processor 
EEE 3 
Help wait on 
ise? gt main ; Execute from RESET to main 








wait off 


step h 







300000 
E4 CLR A 

Fn MOVX @DPTR,A 
120 3F 4 LCALL ClearDispl 







7801 MOV _R3,#01 wend 

7A00 MOV  R2.#00 

7900 MOV R1.#00 

caaa PUSH 63 command on 
cuuz PUSH 02 : 

caû1 win off 


PUSH 





mo retry_count 
mo packet number 
mo index 

mo line_error_count[index] 


%no of steps=0 
command off 
while %no_of steps < 10 


%no of steps = %no of steps + 1 


/autokey: \ALT-A\ 
g Ot write_p1_signature 
/autokey:’\ALT-Q\Y’ ; Quit 


; Monitor key variables in program 


; Initialise the loop variable. 
; Step 10 times. 


; Increment the 
sloop variable 


; Activate a trigger 
; Run the program 
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Bij het opzetten van testprocedures voor 
embedded software gelden de volgende bijzon- 
dere eisen : 

a) De software moet volledig in real-time lopen, 
zonder dat de test hierop ingrijpt. 

b) Veiligheids- en performancekritische toepas- 
singen vereisen meting t.o.v. exacte vooraf 
vastgestelde specificaties. Statistische metin- 
gen of ‘blind-spots’ zijn hierbij niet gewenst. 

c) De testen moeten worden uitgevoerd op de 
uiteindelijke produktieversie van de software. 

d) Validatie vereist het testen van alle systeem- 
functies, in het bijzonder ook met asynchrone 
stimuli. 

e) Een zeer hoog nivo van softwarekwaliteit is 
al vereist bij de initiële produktrelease. 


Het zal uit het bovenstaande duidelijk zijn dat 
gereedschappen die alleen in de hostomgeving 
werken beperkt zijn in hun toepassing bij 
embedded software. 


5 Een goede basis... is het 


halve werk 

Juist bij de ontwikkeling van embedded software 
is het belangrijk te werken op basis van een kwa- 
litatief hoogwaardig ontwikkelproces en ontwik- 
kelgereedschappen. Steeds meer bedrijven- 
overwegen bijvoorbeeld de toepassing van een 
CASE omgeving en Top-Down ontwikkeling. In 
de telecommunicatie waar veel complexe pro- 
jecten plaatsvinden waaraan niet alleen hoge 
kwaliteitseisen worden gesteld, maar die ook 
onder hoge tijdsdruk staan wordt veel gebruik 
gemaakt van de formele specificatietaal SDL 
(Specification and Design Language) [Ref 12] 
waarbij uitgaande van een formele beschrij- 
vingstaal het systeem geverifieerd en gevali- 
deerd kan worden waarna automatisch de C- 
code gegenereerd kan worden. In combinatie 
met message-based Real-Time Operating Sys- 
temen (R.T.O.S.) als OSE van Enea Data kan 
zo vrijwel het gehele systeem automatisch ge- 
genereerd worden. Juist bij het R.T.O.S. is ook 
veel winst te behalen. Zo is er tegenwoordig een 
gedistribueerd R.T.O.S. beschikbaar dat gecer- 
tificeerd is voor veiligheidskritische toepassin- 
gen (TUV, IEC1508) zoals in de petrochemische, 
medische en nucleaire industrie. Het spreekt 
voor zich dat een dergelijk systeem ook grote 
voordelen biedt bij iets minder veeleisende toe- 
passingen. 


Zo ver hoeven we het echter niet per se te zoe- 
ken. Ook het consequent gebruik van een goed 
versiecontrole systeem en gecertificeerde C- 
compilers of andere codegeneratoren vormen 
al een hele belangrijke stap in de goede rich- 
ting. 


3.6 Klassieke S.Q.A. tools. 


Zoals gezegd zijn er nog maar weinig gereed- 
schappen voor S.Q.A. in embedded systemen 
beschikbaar. Dit geldt in het bijzonder voor de 
testfase. Voor de debugfase vormt de In-Circuit 
Emulator een gunstige uitzondering. Dit instru- 
ment is al vele jaren beschikbaar voor de popu- 
laire microprocessors en biedt een vrijwel on- 
geëvenaarde combinatie van controle over de 
executie van software en visualisering van wat 
er in het target gebeurd is. Indien een In-Circuit 
Emulator gebruikt wordt met een moderne 
Source- en Assembly level debugger beschikt 
men over een voldoende krachtige oplossing 
voor de debugfase. 


Voor de testfase heeft een In-Circuit-Emulator 
(ICE) echter maar een beperkte toepassing. Hij 
kan uitstekend ingezet worden voor de uitvoe- 
ring van de testcase door middel van de beschik- 
bare macrotaal. Maar net als de logic-analyzer 
heeft hij een groot aantal beperkingen als het 
gaat om metingen in de testfase. 
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3.6.1 De Test-macrotaal 


Voor automatische executie van regressietesten 
is het noodzakelijk dat op een eenvoudige wijze 
steeds dezelfde test kan worden uitgevoerd, 
waarbij een groot aantal teststimuli gegenereerd 
moet kunnen worden. Door de grote mogelijk- 
heden die een ICE biedt is dit instrument hier- 
voor uitermate geschikt, indien deze is voorzien 
van een krachtige Test-macrotaal. Hierbij moet 
het instrument in staat zijn met de symbolische 
functie- en procedurenamen te werken, zodat 
ook nadat een nieuwe softwareversie is gege- 
nereerd nog steeds dezelfde test kan worden 
gebruikt, doordat de symbolische waarden au- 
tomatisch verwijzen naar de nieuwe absolute 
adressen. Ook moet het mogelijk zijn lokale va- 
riabelen in de testroutine te gebruiken en resul- 
taten weg te schrijven naar een file voor latere 


analyse. 
| Meettijd | 


Statistisch 


Communicatie (geen meting) 


3.7 Een nieuwe generatie 
S.Q.A. gereedschappen. 


Sinds enkele jaren zijn er gereedschappen van 
een nieuwe generatie beschikbaar gekomen die 
de eerder genoemde problemen niet hebben. 
Het geheim hierbij is dat door toepassing van 
een lokale datareductor in een meetprobe de 
meetinformatie continue verwerkt wordt en al- 
leen de uiteindelijke meetresultaten voor pre- 
sentatie en verdere verwerking naar een host- 
systeem doorgegeven worden. Dit systeem is 
vroeger voor het eerst door de firma North- 

West Instrument Systems (NWIS) toegepast, en 
wordt nu gebruikt door Ashling Microsystems in 
haar In-Circuit Emulatoren voor 8/16-bit 
microcontrollers (System Execution Analyzer 
optie) en door Applied Microsystems Corp. 
(CodeTEST) voor de high-end 16/32 bit micro- 


Statistische versus NIET-Statistische meting 


Meettijd | 








Med Continue meting 
Start meting 


Niet-Statistisch 


6.2 Beperkingen van de 
klassieke gereedschappen 


Waarin ligt de beperking van de klassieke tools 
voor S.Q.A. ? Het probleem is dat deze tools 
ontwikkeld zijn voor het vinden van problemen 
(debugging) en niet voor continue meting aan 
software. Zowel een logic analyzer als ICE wor- 
den hiervoor wel ingezet, maar de beperking ligt 
vooral in het feit dat deze instrumenten alleen 
statistische metingen kunnen uitvoeren. Beiden 
programmeren bijvoorbeeld voor 
performance metingen het trace-sys- 
teem (state-analyzer) om aan een aan- 
tal functies of modulen van de software 
te meten. Helaas is de grootte van dit 
tracegeheugen beperkt, meestal tot 
maximaal 10.000 ‘frames’. Als dit ge- 
heugen vol is moet de informatie naar 
een hostcomputer worden verzonden 
via een communicatiekanaal. Tijdens 
deze communicatie ligt de meting stil. 
Hierbij is in de praktijk de ‘dode’ tijd 
(zeer) lang ten opzichte van de meet- 
tijd. 


Probe 


Het zal duidelijk zijn dat voor een be- 
trouwbare performance-analyse een 
niet-statistische of continue meting 
noodzakelijk is. Een ander probleem is dat de 
logic-analyzer en de ICE maar een beperkt aan- 
tal functies in de gaten kan houden, meestal ca. 
10 . Dit betekent dat er van te voren bepaald 
moet worden aan welke kritische functies we wil- 
len meten of dat er zeer vele verschillende me- 
tingen nodig zijn. Dit laatste maakt niet alleen 
het statistische element van de meting nog veel 
groter, maar vergt vooral veel tijd en moeite bij 
het opzetten van deze verschillende metingen. 
Nog groter wordt het probleem bij de huidige 
generatie 16/32 bit CPU’s, waarbij door het ge- 
bruik van intelligente ‘pipelines’ en z.g.n. ‘caches’ 
de informatie op de bus van de processor niet 
meer volledig is. Soms worden instructies van- 
uit de cache uitgevoerd zonder dat dit op de bus 
te zien is, of worden juist instructies die wel- 
ingelezen zijn vanuit het geheugen niet uitge- 
voerd. Bij instrumenten die geheel van de ex- 
terne bus van de processor afhankelijk zijn ont- 
breekt deze informatie. 

Van een 100% betrouwbare meting is in alle bo- 
vengenoemde gevallen geen sprake meer ! 


Principeschema van de System Execution 
Analyzer van Ashling Microsystems 


Hf a 





processors. 


Het bovenstaande principeschema verduidelijkt 
het een en ander. Via een probe en een FIFO- 
register komt de informatie van de adres- en 
databus van de microprocessor bij een 
datareductor terecht. Deze datareductor is ge- 
programmeerd om bijvoorbeeld de ‘entry-’ en 
‘exit-’adressen van bepaalde functies, modulen 
of RTOS taken te volgen. Afhankelijk van het 
algoritme waarvoor de datareductor is gepro- 










Algoritme 






FIFO buffer DATA - 









REDUCTOR 


Naar Hos 


grammeerd zal de datareductor de informatie 
in real-time verwerken. Voor performance-ana- 
lyse met Min/Max executietijden gebeurt bijvoor- 
beeld het volgende. 


Als het ‘entry-adress’ van een functie ‘testmeting’ 
binnenkomt zal de datareductor het exacte tijd- 
stip waarop dit gebeurt vastleggen in het data- 
geheugen. Als nu enige tijd later het bij deze 
functie behorende ‘exit-adress’ verschijnt zal de 
datareductor het tijdsverschil (is de executietijd 
van deze functie) vergelijken met de voorgaande 
minimum- en maximum-executietijd. Als de 
nieuwe tijd korter is dan het voorgaande mini- 
mum, of langer is dan het voorgaande maximum 
zal de tabel overeenkomstig bijgewerkt worden. 
De inhoud van deze tabel met absolute min/max 
executietijden wordt weer doorgegeven aan het 
host-systeem. In de praktijk blijkt dat we zelfs 
voor de huidige zeer snelle 32-bit RISC proces- 
sors op deze manier een 100 % continue me- 
ting kunnen halen, waarbij de FIFO dient om 
een eventuele snelle opeenvolging (burst) van 
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= de software aangebracht 
die twee vaste adressen 
gebruiken en zo de 
datareductor een handje 
helpen. De datareductor 
zal nu pas een entry of exit 
van een functie detecteren 
als de CPU het meetpunt 
bereikt, waarna deze infor- 
matie op de bus komt. Dit 
lijkt een drastische aan- 
pak, maar valt in de prak- 
tijk erg mee. Bij hostsoft- 
ware wordt al heel lang ge- 
bruik gemaakt van instru- 
_ mentatie, en ook een aan- 
_ tal RTOS maken gebruik 
van debug-codes. Het bij- 
zondere is dat Applied 
Microsystems er in ge- 
slaagd is een robuuste 
automatische instrumen- 
tatie uit te voeren met zeer 
weinig ‘overhead’. Daarbij 
is deze standaard direct 
opgepakt door alle belang- 
rijke fabrikanten van R.T.O.S. die de ‘meetpunten’ 
al hebben opgenomen in hun produkt. Het is ver- 
der nog belangrijk op te merken dat het voor de 
softwarefabrikant toegestaan is om de ‘meet- 















write count 
cuunt--; 
inc_dword(bsub_counter] 2J); 


8) PC=6887 A=00 B-34 SP-2223 
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PathFinder 11 for Wi. 


NIET-Statistische Min/Max executietijd meting; CTS- 
emulator van Ashling Microsystems. 


entry’s of exit’s tijdelijk op te vangen (denk aan 
recursieve routines) 


Door nu het algoritme dat gebruikt wordt door 
de datareductor aan te passen kun- 
nen verschillende metingen uitge- 
voerd worden. 
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7.1 Oplossingen voor 
high-end 16/32-bit 


processors. 

Voor de kleinere 8/16-bit processors 
zijn hiermee alle problemen opgelost, 
maar voor de krachtige 16/32-bit | 
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Al deze processors worden tot de maximale 
snelheden ondersteund ! Bovendien is er een 
universele probe beschikbaar waarmee alle 
overige processors tot 66 Mhz in principe on- 
dersteund worden.Hiermee ondersteunt men bij- 
voorbeeld zelfs de PowerQUICC CPU. Om een 
verbinding met de CPU tot stand te brengen is 
het ook mogelijk een logic-analyzer adapter te 
gebruiken. In principe is een verbinding met de 
bus voldoende. 


8 Metingen voor S.Q.A. in 
een embedded omgeving. 


Op dit moment zijn er al diverse metingen mo- 
gelijk met de genoemde instrumenten. Er wordt 
nog gewerkt aan uitbreiding hiervan. Bij al deze 
metingen wordt, m.u.v. de control-flow trace, ge- 
bruik gemaakt van de lokale datareductor. Het 
opzetten van de meting is hierbij zeer eenvou- 
dig. De gebruiker kiest aan welke RTOS-taken, 
modulen en functies de meting verricht moet 
worden of selecteert ze allemaal (tot een maxi- 
mum van 32.000). Hierna wordt de meting ge- 
kozen en enkele seconden later worden de eer- 
ste resultaten zichtbaar. Hierbij kan de gebrui- 
ker direct zien wat de invloed is van een nieuwe 
test of bijvoorbeeld een interrupt. Het systeem 
meet continue zonder een executiecyclus te 
missen en geeft elke paar seconden de resulta- 

ten weer op het hostsysteem. Uiteraard | 


5) kunnen de resultaten in de vorm van rap- 


Help 


porten uitgeprint of bewaard worden voor 
TH latere analyse. Het is ook mogelijk op ba- 









meten of de resultaten van verschillende 
metingen te combineren. 









8.1 Performance 
analyse 





ee 
Mas Avg 


RISA uS 


CPU's is dit maar een deel van de op- | 
lossing. Ten eerste maken deze CPU’s 
intensief gebruik van een interne | 
pipeline en/of cache, waardoor er ——— 
adressen op de bus verschijnen die 
nooit geëxecuteerd worden. Of worden er | 
juist adressen geëxecuteerd vanuit de | 
cache, die niet op de bus verschijnen. Bo- 
vendien werken deze applicaties vaak met 
dynamische Real-Time Operating Syste- 
men, waarbij een zelfde adres overeen kan 
komen met verschillende functies, modules 
of RTOS-taken. Om dit probleem te onder- 
vangen heeft Applied Microsystems geko- 
zen voor een proces van automatische in- 
strumentatie van de source-code. 
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CodeTEST : Performance meting op RTOS-Task 
en functie nivo. 


punten’ in de code te la- 
ten zitten bij aflevering, 
iets wat vooral bij DOD- 
STD-2167A belangrijk is. 
Het systeem kan 32.000 
functies in een meting en 
continue volgen ! 


Hierbij worden automatisch op 
source-code nivo meetpunten in 









i % Coverag 





edemone 


7.2 Processor 


ondersteuning 
Van de eerder genoemde 
fabrikanten zijn ge- 
reedschappen lever- 
baar die op een NIET- 
Statistische basis me- 
tingen kunnen verrich- 
ten voor vrijwel alle po- 
pulaire microproces- 
sors en controllers. 
Ashling ondersteunt 
o.a. de 8051, 8051-XA, 
68HC11, en de 80196 
= families en Applied 
Microsystems de Moto- 
rola en Intel processors 
uit de 68xxx, PowerPC, 
80x86 en 1960 families. 
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Met de performance analyzer is het mo- 
gelijk executietijden en intervallen te 
meten van zowel functies als RTOS-ta- 
ken. De gebruiker kan hierbij continue 
zien welke taken en functies execute- 
ren, hoe vaak ze zijn geëxecuteerd, wat 
de absolute minimale- en maximale 
executietijden hierbij geweest zijn, de 
cumulatieve executietijd gedurende de 
meting en de executietijd als percen- 
tage van de totale executietijd. 


Ook is het mogelijk te zien welke RTOS 

taken de CPU-tijd gebruiken en hoeveel 

kopieën van dezelfde taak er actief zijn. 
Door gebruik te maken van krachtige zoek- en 
sorteer routines kan snel een goed overzicht van 
de prestaties van zowel het systeem als geheel 
als op het meer gedetailleerde functie-nivo ver- 
kregen worden. 


Met deze niet-statistische performance analyse 
kan zoals eerder opgemerkt in een meting een 
worst-case executietijd rapport gegenereerd 
worden voor de gehele systeemsoftware. Hier- 
bij is de meting 100% betrouwbaar, met andere 
woorden, ook als een keer in de gehele test- 
duur de executie van een functie of module door 
een onverwachte combinatie van interrupts iets 
langer duurt dan zien we dit terug in de rappor- 
ten. De meettijd is hierbij in principe onbeperkt. 
Als alternatieve meting biedt de CodeTEST nog 
het z.g.n. ‘Call-Pair Linking’. Hierbij is te zien is 
hoe vaak bepaalde subroutines worden aange- 
roepen en door wie... Wanneer bijvoorbeeld blijkt 
dat een bepaalde korte routine vaak wordt aan- 
geroepen door dezelfde ‘caller’ kan het efficiënt 
zijn deze subroutine in de ‘calling’-routine op de 
nemen als in-line code. Dit bespaart ten koste 
van een klein beetje programmageheugen veel 
executietijd en stack-ruimte, die eerst gebruikt 
werd voor de aanroep van de subroutine. 
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De Control-Flow Trace 
is een uitbreiding op de 
bekende Assembly- en 
Sourcelevel trace. Door 
toepassing van een 
groot geheugen en al- 
leen de registratie van 
de beslissingspunten 
(decision-points) in een 








/* of currently allocated blocks... 





if (nAtlocated < nth) 






é*... then we'll allocate another. wf E 


/* Figure out how big to make it. We're trying to allocate */ 
7* varying sized blocks, with larger ones less likely, */ 











ror 3 il trace-buffer kan het ef : ; 
| Error at line 63 in function exmali| Menen lana slze = NOIM KOI (mesten) + 0; | CodeTEST systeem Institute of Electrical and Electronics 
rror at lide Ea in Function Monat i je seueehts ainete bled nne ge E 4 Engineers, Inc, 345 East 47th St., New York, 





een executie-history op- 
slaan van het equivalent 
van ca. 100.000 source 
regels. Hierbij is een 
nauwkeurige time- 





| Error at line 63 in function exmall 
| Errar at line 63 in function exmall 
| Error at line 63 in function exmali 
| Error at line 63 in function exmali 
‘| Error at line 63 in function exmalt 
Į Error at line 63 in function exmalt 
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| Error at line 63 in function exmall 
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/*. link it onto the allocated list, and fill it in. */ 















| Error at line 63 in function exmalt 
| Error at line 63 in function exmall 


bloek->size = sizeof (Hock) + size; 
Allocated = block 
nAllocated += 1; 






RE | 





block >next = Allocated: | 


f stamp aanwezig. Zo 
| wordt het mogelijk op 
i het nivo van RTOS-ta- 
ken en functies de ‘Flow’ 


7* One time in ten, we'll cause some kind of error.. / 











CodeTEST/Memory : Memory allocation error detection 


Een performance analyzer wordt ook wel profiler 
genoemd, omdat er een profiel ontstaat dat aan- 
geeft waar de processor zijn tijd aan besteed. 
Dit dekt echter niet de gehele lading. Het is bij- 
voorbeeld ook mogelijk om in te schatten of er 
nog executietijd ‘over’ is voor het toevoegen van 
extra functionaliteit en voor het bepalen van 
‘worst-case’ executie- en responsetijden. 


8.2 Code Coverage 


Bij Code Coverage wordt bijgehouden welke 
code wel en welke code nog niet geëxecuteerd 
is. Deze meting is vereist bij projecten volgens 
DOD-STD-2167A. Het bewijst namelijk dat de 
code op zijn minst eenmaal uitgevoerd is. Dit 
zegt op zich natuurlijk niets over de kwaliteit of 
de functionaliteit van de code, maar des te meer 
over de volledigheid van het testplan. Vooral bij 
de opbouw van dit testplan kan de Code 
Coverage meting ook goede diensten bewijzen 
omdat er direct te zien is op Task, module of op 
Source-code nivo welke code nog niet getest 
is, zodat het testplan overeenkomstig aangepast 
kan worden. Bovendien is het mogelijk rappor- 
ten te genereren die een overzicht geven van 
de progressie in de testcoverage die in de ver- 
schillende testen wordt bereikt, zodat snel inef- 
ficiénte testen geélimineerd kunnen worden. 


8.3 Memory Allocation 


In embedded systemen vormen de memory-al- 
locatie problemen misschien wel de meeste ge- 
vaarlijke en lastigst op te sporen problemen. 
Vooral bij het gebruik van een R.T.O.S. is het 
moeilijk een goede indruk te krijgen van het dy- 
namische geheugen gebruik, terwijl er ook snel 
een ‘geheugen-lek’ kan ontstaan, een situatie 
waarbij door een proces ‘vergeten’ wordt het ge- 
alloceerde geheugen weer vrij te maken. Het 
CodeTEST systeem is in staat te rapporteren 
hoeveel geheugen er door welke functies via 
welke allocatieroutines ge-alloceerd wordt, hoe 
vaak dit gebeurt en in welke blokgroottes. Bo- 
vendien is het totale aantal ge-alloceerde bytes 
dynamisch te volgen. Als extra is het systeem 
in staat foutmeldingen te geven voor een aantal 
veel voorkomende allocatie problemen zoals 
‘out-of-heap’, ‘null-pointer’, ‘invalid-block-size’ 
etc, etc...... 

Met deze meetoptie is het mogelijk geheugen- 
lekken al in een vroeg stadium te ontdekken en 
in te schatten of er nog geheugen ‘over’ is voor 
toekomstige opties. Ook wordt hiermee een ana- 
lyse mogelijk van de software performance in 
verhouding tot het beschikbare geheugen ! 
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van de software te vol- 
gen en te analyseren. 
De trace kan op Task, 
Control-Flow en 
Source-level bekeken 
worden. Dit vergemakkelijkt het meten van de 
‘echte’ responsetijd van het systeem en verifi- 
catie van alle beslissingpunten (decision-points) 
in de software. 


9 Conclusie. 


Hoewel Software Quality Assurance voor 
embedded software geen eenvoudige zaak is, 
zijn er methoden en gereedschappen beschik- 
baar waarmee het in toenemende mate moge- 
lijk is het software ontwikkelproces te verbete- 
ren en metingen aan de kwaliteit van de soft- 
ware te verrichten en de resultaten vast te leg- 
gen in rapporten. Hiermee wordt het mogelijk 
bij een eindprodukt een volledige set rapporten 
af te leveren waarin aantoonbaar is wat de pres- 
taties van het eindprodukt zijn t.o.v. de specifi- 
caties. Als gevolg hiervan is het mogelijk het soft- 
ware ontwikkelproces beter te beheersen en de 
risico’s te verkleinen. 
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Distributed Debugging Tasks 


Effectief ontwikkelen van embedded applicaties wordt 
steeds belangrijker, en de verwachting is dat het in de na- 
bije toekomst alleen nog maar belangrijker wordt. 


Er worden steeds nieuwe manieren ontdekt en 
ontwikkeld om de verschillende problemen op 
te lossen. Vaak zien we dat de elektronica 
ontwikkelgereedschappen uit verschillende on- 
derdelen bestaan zoals PC-debuggers, Target 
Monitoren, In Circuit Emulators (ICE) en Logic 
Analysers. Elk instrument wordt dan voor een 
specifieke taak ingezet. Door hogere snelheden, 
grotere complexiteit en de snelle opvolging van 
processor-generaties ontstaan er problemen 
met In-Circuit Emulators. Leverproblemen, het 
niet beschikbaar komen van een emulator voor 
een bepaalde processor omdat de markt te klein 
wordt geacht, of een bepaalde afgeleide pro- 
cessor wordt niet ondersteund, waardoor de 
vertrouwde werkwijze wegvalt. Een mogelijke 
oplossing is het gebruik van een Logic Analyser. 
Maar de bekende stand-alone analyser biedt 
geen optimale oplossing. Hij moet voorzien zijn 
van een voor ontwerpers bekende gebruikers 
interface en operating systeem. Dit is nodig om 
eenvoudig met andere gereedschappen te kun- 
nen werken, en zorg te dragen voor een sim- 
pele communicatie. Ook moeten de functies van 
de analyser te besturen zijn. Met de steeds klei- 
ner wordende behuizingen van de processoren 
en de steeds grotere hoeveelheid pinnen kan 
de ICE wel beschikbaar zijn, maar fysisch niet 
aangesloten worden (CQFP, BGA). De beste 
manier om de Logic Analyser aan te sluiten is 
met een ‘debug pin array’. Die wordt bij het ont- 
werpen van het target op een goed bereikbare 
plaats neergezet en voorkomt zo dure en spe- 
ciale adapters. Als het aansluiten elektrisch of 
mechanisch niet mogelijk is op de processor dan 
kan er bij een Logic Analyser ook nog op an- 
dere plaatsen verbinding gemaakt worden bij- 
voorbeeld via databus buffers, adreslijnen etc. 
Het grote voordeel van deze opzet is de ‘pro- 
cessor onafhankelijkheid’. Wanneer er een an- 


dere processor gekozen wordt dan is alleen een 
andere kabel nodig en moet er natuurlijk andere 
software in de analyser geladen worden. De 
debug-tool is zo direct weer gereed voor een 
ander project. Ook kan de gebruiker een eigen 
specifieke disassembler of data interpreter 
schrijven (voor bijvoorbeeld ASICs met een spe- 
cifieke processor) en zo vertrouwelijke informa- 
tie beschermen. Wanneer meer kanalen nodig 
zijn kan dit door een analyser-board bij te plaat- 
sen. 


Voorwaarde voor deze methode is dat de Logic 
Analyser niet alleen ‘Disassembler’ en ‘Symbolic 
Adresses’ ondersteunt, maar daarnaast ook si- 
multaan High Level Language (HLL). Deze HLL 
werkt op hetzelfde platform als de Logic 
Analyser software (Windows 3.11, 95 of NT) en 
geeft de source code weer die door de proces- 
sor gebruikt is, gerelateerd aan de real-time data 
van de Logic Analyser. 


De Logic Analyser fungeert als een real-time 
trace, zonder het target te beinvioeden. De HLL- 
manager is modulair zodat er bij processor wij- 
ziging alleen een symbol- of data-interpreter 
herladen hoeft te worden. In de source code kan 
aangegeven worden waar er getriggerd moet 
worden. Ook Break-Points worden op die ma- 
nier ingesteld (zoals gebruikelijk bij Debugging 
tools). 


Extra gebruikersmogelijkheden worden gebo- 
den door triggerlijnen met instelbare trigger le- 
vels. Met dit triggersignaal kan dan een interrupt 
op het target gerealiseerd worden. De applica- 
tie wordt dan gestopt en een ‘Target Monitor’ 
wordt geactiveerd. De monitor stuurt nu de re- 
levante informatie naar de debugger en de 
debugger displayed de source code, de 


assembler listing, symbol informatie, de status 
van interne registers, globale en lokale variabe- 
len, RAM en ROM status enz. parallel aan de 
real-time trace van de Logic Analyser. De moni- 
tor kan nu gebruikt worden om variabelen te 
manipuleren, stap voor stap door de source- of 
assembler-code te lopen, een nieuwe applica- 
tie te laden of de huidige opnieuw te starten. 
Wanneer een Break-Point gezet wordt op een 
interne variabele, kan de analyser daar niet di- 
rect op triggeren. Om dat te doen wordt er op 
het Break-Point een sprong gemaakt naar de 
Target Monitor, wat een triggeradres beschik- 
baar maakt. In beide hier beschreven gevallen 
stopt het target op het triggerpunt en beïnvloedt 
het real-time gedrag van het target. Als de real- 
time situatie niet door het debugging systeem 
beïnvloed mag worden is er de mogelijkheid om 
het Trigger-Out signaal van de Logic Analyser 
niet aan te sluiten, wat dan resulteert in het 
weergeven van een real-time trace op het 
scherm. Interne variabelen en dergelijke blijven 
onzichtbaar (of er moet een Watch-Point gezet 
worden). Wanneer een Watch-Point bereikt 
wordt dan wordt de waarde door de Target Mo- 
nitor aan external RAM gegeven en is dus be- 
schikbaar voor de Logic Analyser. Dit geeft de 
analyser een gedefinieerd trigger punt. 


Een debugging tool zoals hier beschreven be- 
staat uit een Logic Analyser, een PC-debugger 
en een Target Monitor. Deze combinatie geeft 
vrijwel dezelfde functionaliteit en comfort als een 
In-Circuit Emulator maar met de voordelen van 
de aansluitmogelijkheden, flexibiliteit en de on- 
afhankelijkheid van het processor platform. 


Rob Strik 
Tech 5 
Tel: 0184-615551 





Distributed Emulation for Real-time 
Embedded Software Development 


Men ziet dat in digitale systemen de software een steeds 
grotere rol gaat spelen.Waar vroeger veel aandacht werd 
besteed aan de hardware, ziet men nu dat vaak het design- 
team voor een groot gedeelte uit software engineers be- 
staat. Software maakt een produkt flexibel. Het is makkelij- 
ker uit te brengen met verschillende functionaliteiten en kan 
makkelijker worden opgewaardeerd met nieuwe mogelijkhe- 
den. Dit maakt dat de levensduur van een produkt kan wor- 
den verlengd en daarmee de return-on-investment kan 


worden zeker gesteld. 


Verder zien we ook steeds meer dat de ontwik- 
keling van hard- en software parallel loopt. Si- 
mulatie-paketten maken het testen van delen 
van een produkt mogelijk en daarmee is het zo- 
genaamde concurrent engineering een feit ge- 
worden. Maar nog steeds blijken er problemen 
te ontstaan bij de integratie van beide. En vooral 
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die fase in de ontwikkeling vraagt om de beno- 
digde hulpmiddelen. Hardware engineers zul- 
len in deze fase waarschijnlijk terugvallen op de 
logic analyzer. Het instrument is uitermate ge- 
schikt om tijdrelaties weer te geven tussen di- 
verse signalen en zodoende probleemgebieden 
aan te geven. Verder kan gekeken worden naar 


de code die ge-executeerd wordt. Dit kan in hex 
of met behulp van microprocessor-ondersteu- 
ning in assembler. 


De software engineer zal waarschijnlijk niet te- 
rugvallen op een logic analyzer, maar eerder een 
in-circuit emulator kiezen. Dit type van instru- 
ment is uitermate geschikt voor het debuggen 
van real time embedded software en heeft vol- 
doende mogelijkheden om ook tijdens de inte- 
gratie fase zijn diensten te bewijzen. 

Een emulator heeft in het algemeen een logic 

analyzer funktie, maar voegt daar twee funkties 

aan toe: 

1) Run-control geeft de gebruiker de mogelijk- 
heid om code te stoppen om vervolgens naar 
de situatie in de processor of controller te kij- 
ken. Men kan registers of geheugenwaarden 
uitlezen. Verder kan men stap voor stap door 
de code lopen om te zien welke uitwerking 
de geschreven software heeft. 
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2) Overlay-memory kan tijdelijk de ROM of RAM 
van het target bord vervangen. Tijdens het 
debuggen van de code kunnen uiteraard nog 
veranderingen worden aangebracht. Met be- 
hulp van overlay memory is het niet nodig om 
in die fase steeds PROM'’s opnieuw te pro- 
grammeren. Verder is dit geheugen soms 
dual-ported. Dit houdt in dat het bekeken kan 
worden zonder dat de processor daarvan iets 
merkt. Zo kunnen variabelen bekeken worden 
tijdens het draaien van de software zonder 
interupties in de executie ervan. In sommige 
targets is dit een must omdat het anders 
crashed. 


Een emulator is echter een instrument dat spe- 
cifiek voor een bepaalde chip ontwikkeld wordt. 
Door de modulaire opbouw kan het soms zo zijn 
dat hij kan worden omgebouwd als in een vol- 
gend project een nieuwe processor wordt ge- 
kozen, maar het blijft toch een minder algemeen 
inzetbaar instrument dan bijvoorbeeld een 
oscilloscoop of een logic analyzer. 


Een duidelijk aanwezige trend is de steeds gro- 
ter wordende diversiteit van processoren en 
controllers. Steeds vaker zien we dat een groot 


‘aantal derivaten van een bepaalde architectuur 


wordt geintroduceerd. Maar ook zien we dat het 
aantal verschillende architecturen dat gebruikt 
wordt toeneemt. Zelfs chip-fabrikanten komen 
met meerdere produktlijnen parallel uit om de 
verschillende applicatie gebieden te adresseren. 
In het streven naar steeds meer applicatie ge- 
richte oplossingen wordt ook het gebruik van 
een processor als onderdeel van een ASIC 
steeds belangrijker. De grote keuze maakt het 
voor een ontwerper mogelijk om de meest ge- 
schikte chip voor zijn toepassing te kiezen. Voor 
de emulator-fabrikant wordt het echter een 
steeds grotere uitdaging om al deze IC’s tijdig 
te ondersteunen. 


De grote vrijheid in keuze van technologie heeft 
tot gevolg dat zowel de hardware- als de soft- 
ware ontwerper voor een gegeven ontwerp ui- 
terst efficient te werk kan gaan. Het heeft ech- 
ter ook tot gevolg dat een gekozen processor 
minder lang zal meegaan. Met name core-on- 
ASIC oplossingen zullen per ontwerp leiden tot 
andere pen verdelingen of zelfs tot een nieuwe 
behuizing. Al deze veranderingen zorgen ervoor 
dat ten behoeve van de processor (of behuizing) 
specifieke delen van de instrumentatie vervan- 
gen moeten worden. Bij een logic analyzer is dit 
een minimale investering, bij een emulator 
daarintegen is dit een signifikant deel van de 
totale kosten van het instrument. Voor die ont- 
werpen die gebruik maken van processoren met 
een grote rekencapacitiet, vaak verbonden aan 
een hoge klok frequentie, wordt de invloed die 
de instrumentatie uitoefent op het ontwerp be- 
langrijk. Op dit gebied heeft de logic analyzer 
een duidelijk voordeel. De probing nodig voor 
een funktionele logic analyzer aansluiting is 
minderbelastend dan die voor een in circuit 
emulator. 


De bovengenoemde zaken zijn voor Hewlett- 
Packard reden geweest om te zoeken naar een 
oplossing met de flexibiliteit van een logic 
analyzer en de kracht van de in circuit emulator, 
de Distributed Emulator. Bij een distributed 
emulator worden de funkties van een in circuit 
emulator opgesplitst in afzonderlijke, met stan- 
daard instrumenten invulbare, componenten. De 
logic analyzer zorgt voor de real time analyse 
mogelijkheden. Voor run control wordt gebruik 
gemaakt van de mogelijkheden van de al regel- 
matig aanwezige on-chip debugger (N-wire 
interface, bv. BDM bij de Motorola 68360), of een 
ROM monitor. Overlay geheugen kan worden 
ingevuld door het vervangen van de ROM’s door 
RAM, of door een ROM vervanger. Belangrijk 
bij een Distributed Emulator is de samenwer- 


king tussen de verschillende delen, de manier 
van aansturing en data presentatie. Bij de 
distributed emulator oplossing is de logic 
analyzer zo aangepast dat de gebruiker de data 
in de gebruikte programmeertaal gepresenteerd 
krijgt en de instellingen direct vanuit de source 
gemaakt kunnen worden. De analyzer kan ge- 
bruikt worden om, in real time, het target te be- 
kijken en bij het voorkomen van een bepaald 
verschijnsel de processor te stoppen. Nadat de 
processor stopt met het uitvoeren van het pro- 
gramma gaat de controle terug naar de ge- 
bruikte debugger. 

De verschillende onderdelen van de distributed 
emulator kunnen grotendeels aangepast wor- 
den aan de eisen van de gebruiker. De logic 
analyzer kan varieren in snelheid, geheugen- 
diepte en analyse capacitieten. De run control 
kan varieren tussen een ROM monitor en het 
gebruik van on-chip mogelijkheden. De 
debugger en het gebruikte taalsysteem zijn ge- 
heel naar keuze van de gebruiker. Zo kan geko- 
zen worden voor de meest optimale oplossing 
voor het ontwerp. 

Aanpassingen voor een volgend ontwerp kun- 
nen eenvoudig gemaakt worden zonder dat de 
komplete instrumentatie afgeschreven dient te 
worden. Een verandering van processor 
technology kan op deze manier eenvoudig door- 
gevoerd worden, de gehele bediening en de ge- 
bruikers mogelijkheden blijven echter gelijk. 


Kortom, de Distributed Emulator maakt het mo- 
gelijk om een diversiteit van processoren te on- 
dersteunen. Het geeft een tijdige en flexibele op- 
lossing, naast de traditionele in-circuit emulator 
en is ook makkelijk in te zetten in volgende pro- 
jecten. 


Hewlett Packard Nederland B.V. 
Bert Esser 
Tel: 020-5477502 





Keuze-criteriums bij het opzetten 
van real-time en Embedded 
Software-ontwikkelingen. 


Inleiding 


De toepassing van micro-elektronica bij de ontwikkeling van 
een product neemt nog altijd een belangrijke plaats in. In de 
nog steeds groeiende elektronica-markt zijn er drie zaken 


vooraf zeker: 


- consumenten worden veeleisender ten aan- 
zien van nieuwe producten 

- product life-cycles’ worden steeds korter 

- (te) laat op de markt komen met een nieuw 
product kan fataal zijn. 

Dit betekent voor de ontwikkeling van zowel voor 

bestaande als voor nieuwe producten dat er 

steeds sneller dient te worden ingespeeld op 

nieuwe technologieën. 


Gelukkig komen er steeds meer (nieuwe) ont- 
werp-hulpmiddelen (tools) beschikbaar welke 
essentieel zijn om de toenemende complexiteit 
te kunnen beheersen en een kortere ‘time-to- 
market’ van een project te kunnen realiseren. 
Hierbij wordt de kans op vertragingen zoveel 
mogelijk gereduceerd. Kortom de productiviteit 
neemt aanzienlijk toe. In de praktijk blijkt vaak 
dat de hier bespaarde tijd voor een groot deel 
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wordt geïnvesteerd in de kwaliteit van een 
product, gebruik makende van de mogelijkhe- 
den die de desbetreffende tool te bieden heeft. 
De afweging welke tool voor bepaalde werk- 
zaamheden nu het beste gebruikt kan worden, 
blijkt in de praktijk afhankelijk te zijn van een 
aantal factoren. Zo vallen te noemen, de techni- 
sche mogelijkheden en beperkingen welke be- 
paalde tools met zich meebrengen. De finan- 
ciële consequentie, een tweede factor, kan men 
als direct hiervan afgeleid beschouwen. Een 
derde factor die in een groeimarkt altijd een be- 
langrijke rol speelt, is de factor kennis. Ook ken- 
nis is, naast technische mogelijkheden en finan- 
ciële consequenties, een variabele die uitein- 
delijk bepalend is voor de vraag: zelf doen of 
uitbesteden ? 


6.2 Huidige technische mo- 
gelijkheden 


In het gebruik van tools, welke een steeds ho- 
gere kwaliteit en een steeds groter aantal mo- 
gelijkheden uitstralen, is een aantal trends waar 
te nemen. 

Waar vroeger vrijwel direct op een laag niveau 
in de hardware werd gewerkt, is de trend dat 
het abstractieniveau vandaag de dag steeds 
hoger wordt. Microprocessor-onafhankelijkheid, 
productiviteit en kwaliteit zijn hierbij sleutel- 
begrippen. 

Door het overweldigende aanbod van de be- 
staande en in een hoog tempo nieuw ontwik- 
kelde en te ontwikkelen microprocessoren en 
microcontrollers van een groeiend aantal aan- 
bieders anderzijds, ontstaat er een situatie waar- 
van de product-ontwikkelaar uiteindelijk kan pro- 
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Mogelijkheden 
Debugger 


IN-CIRCUIT 
EMULATOR 


BDM 
DEBUGGER 








fiteren. De keuze van de logica kan namelijk 
steeds beter worden afgestemd op een project. 


Uiteraard dienen serieuze tool-leveranciers op 

beide trends in te spelen. 

Beperken we ons hier tot real-time en embedded 

software ontwikkeling, dan kunnen we stellen 

dat we te maken hebben met afzonderlijke hulp- 
middelen welke gezamenlijk een zogeheten 

‘toolchain’ vormen: 

- design-tools of CASE-tools: een methode wordt 
omgezet in programma-code (bijvoorbeeld 
ANSI-C) 

- compilers/assemblers: high level- en source 
level programma-code wordt vertaald naar 
machinecode 

- debuggers: voornamelijk bedoeld voor het op- 
sporen van fouten waarbij machine code 


via een standaard formaat wordt geladen en 
vanaf het hoogste niveau (high le- 
vel language) kan worden geana- 
lyseerd, waarbij kan worden vastge- 
steld waar een eventuele aanpassing 


hankelijk van de soort debugger kan de 
code worden gesimuleerd of worden 
geëmuleerd. 


Naast de verschillende media en eventuele 

netwerk-omgevingen die worden ondersteund 

om de tools te kunnen bedienen, kent elk hulp- 

middel ook specifieke eigenschappen: 

A) design tools: 

- koppelingen naar grafische ontwerp tools 

- kwaliteit (compactheid, snelheid, etc.) van de 
te gegenereren (veelal ANSI-C) programma- 
code 

- simulatie voor een logische controle van de 
code (dead-ends, etc.) 

- het genereren van dokumentatie 

B) compilers/assemblers: 

- kwaliteit (compactheid, snelheid, etc.) van de 
te genereren machinecode 

- optimalisatie 

- foutcode-generatie 

- instelmogelijkheden 

C) debuggers (simulators, monitors, in-circuit 
emulators, etc.) 

- high/source level ondersteuning 

- real-time gedrag 

- up- en downloadtijd 

- wel of niet real-time tracing 

- aantal ondersteunde devices en de mogelijk- 
heid tot upgrading 

- maximaal ondersteunde snelheden van de 
devices 

- mogelijkheden als (real-time) ‘code-coverage’ 
analyse en ‘program performance’ analyse. 


De kracht van een goede ontwikkelomgeving zit 
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of optimalisatie het meest zinvol is. Af- % \ 
\ 


> 
Complexiteit 
Applicatie 


‘m in feite in de samenbouw van componenten 
uit A), B) en C) tot een geïntegreerd geheel 
waarbij alle componenten op het desbetreffende 
project zijn afgestemd. Verder kent elk project 
een bepaalde omvang, zodat er bij grotere 
ontwikkelprojecten ook in een parallelle opzet 
door verschillende personen, al dan niet in een 
netwerk-omgeving, optimaal van de tools ge- 
bruik gemaakt kan worden. 


Op dit moment wordt er door de huidige toon- 
aangevende tool-leveranciers erg veel aandacht 
besteed aan een verdere integratie van de af- 
zonderlijke tools. De verscheidenheid aan 
keuzemogelijkheden zorgt ervoor dat er goed 
op bestaande en nieuwe situaties kan worden 
ingespeeld. 


Afhankelijk van de visie van de tool-fabrikant 
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Hierbij valt bij-___\ voorbeeld te 
denken aan \ \ ethernet-om- 
gevingen en aan \ verschillende 
drivers voor \ operating 
systems van di- X verse PC- en 
werkstation-omge- vingen, inclusief 
high level language support voor de te 
ondersteunen compilers. 

Verder kunnen we hierbij ook denken in de rich- 
ting van de verscheidenheid aan te ondersteu- 
nen microprocessoren/-controllers, waarbij de 
trend duidelijk is: toenemende integratie, hogere 
snelheden en kleinere behuizingen. 

De opmars van Windows-omgevingen met een 
gestandaardiseerd ‘look and feel’ user-interface 
hebben de basis gelegd voor de verdere inte- 


wx 


& 
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gratie tussen de verschillende tools in een 
toolchain. 


6.3 Financiële 


consequenties 

Vaak gaan technologische ontwikkelingen ge- 
paard met een zich voor de eindgebruiker gun- 
stig ontwikkelende prijs. Waar zo’n vijftien jaar 
geleden een hoge prijs werd betaald voor een 
stand-alone ontwikkelomgeving met een be- 
perkte functionaliteit, wordt er nu voor een frac- 
tie van dit bedrag een geïntegreerde toolset ge- 
leverd voor een bepaalde microprocessor- of 
microcontroller-familie met uitgebreide mogelijk- 
heden. Uiteraard inclusief de hiervoor beschre- 
ven state-of-the-art features. 

Hierbij is vooral de flexibiliteit toegenomen; de 
meeste tools zijn upgradable, zowel qua moge- 
lijkheden als qua groei naar andere en/of ho- 
gere microprocessor/-controller families. 


Er is tevens een taak weggelegd voor de leve- 
rancier van de ontwikkeltools om de klant waar 
nodig een totaaloplossing te bieden. Hierbij 
wordt vaak een oplossing gezocht in een mo- 
gelijke inruil van de apparatuur (of delen hier- 
van), leasing van apparatuur en huur- 
mogelijkheden. 


Omdat de time to market steeds korter wordt 
en dit ondermeer mogelijk wordt gemaakt door 
de kwaliteit en de mogelijkheden die de tools 
ons bieden, wordt er ook gebruik gemaakt van 
de mogelijkheid om apparatuur voor een korte 
periode te huren. Door de relatief lage aanschaf- 
prijs van de tools is dit meestal alleen interes- 
sant voor zeer kortlopende projecten. Gezien het 
kortstondige gebruik komt hierbij vaak tevens 
een training om de hoek kijken. 


Naast diverse technische afwegingen zien we 
dus ook dat er financiële afwegingen dienen te 
worden gemaakt om tot een verantwoorde in- 
vestering over te kunnen gaan. Uiteraard is ie- 
dere situatie verschillend, zo- 
dat de uiteindelijke beslissing 
steeds opnieuw dient te worden 
gemaakt. In ieder geval blijft de 
vraag: hoe kan de verhoogde 
productiviteit voor mijn bedrijf iets 
opleveren ? 


6.4. Zelf doen of 
uitbesteden. 


Naast het zelf direct investeren in hulpmid- 

delen voor een nieuwe ontwikkeling, zijn er 
natuurlijk ook mogelijkheden om een project te 
laten uitvoeren door externe specialisten. Dit kan 
een uitkomst zijn om bijvoorbeeld capaciteit, 
kennis en tools al dan niet tegen een ‘fixed price’ 
in huis te kunnen halen. Vandaag de dag zijn er 
om die reden veel aanbieders op de IT-markt 
die zich meer en meer op de groeiende markt 
van embedded software richten. 





We noemen hier een aantal mogelijkheden. 

- Het door middel van een toegesneden cursus 
een bepaalde technologie eigen maken, 
waardoor de ontwikkeling zelf kan worden 
gedaan (training). 

- Het op laten zetten van een nieuwe of be- 
staande ontwikkeling, waarna er na afloop 
een kennisoverdracht plaatsvindt (assisten- 
tie). 

- Het inhuren van een tijdelijke embedded soft- 
ware-specialist (soms zelfs inclusief de be- 
nodigde apparatuur) voor een vooraf afge- 
sproken termijn en opdracht (detachering). 

- Het in zijn geheel uitbesteden van een project 
aan een extern ontwikkelbureau (project ba- 
sis; fixed price, fixed date). 


Vaak wordt er vooral bij consultancy en engi- 
neering, gezocht naar partners met een desbe- 
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treffend specialisme. Ook hier is een taak weg- 
gelegd voor de tool-leverancier, die door een toe- 
nemende betrokkenheid met zijn afnemers, vaak 
zeer goed op de hoogte is van bepaalde kennis 
in specifieke deelgebieden. 


6.5 De rol van een tool- 
leverancier bij het opzetten 
van real-time en Embedded 
Software ontwikkelingen 


Zoals gezegd, houdt een leverancier zich van- 
daag de dag niet alleen bezig met het leveren 
en ondersteunen van een breed aanbod van 
goed op elkaar afgestemde hulpmiddelen. Van 
een goede leverancier mag worden verwacht dat 
de ondersteuning wordt aangevuld met dienst- 
verlening. 


Dienstverlening waaron- 

der in de praktijk mag 

worden verstaan: 

- upgrading door even- 

tuele inruil van appa- 

ratuur; 

een uitgebreid train- 

ingsprogramma met 

naast uiteraard pro- 

ducttrainingen, ook 

aandacht voor technologietrainingen; 
referenties naar de markt van zowel toe- 
leveranciers van producten (chips, half- 
fabrikaten, etc.), alswel van diensten (engi- 
neering, consultancy, etc.). 

De productgroep ontwikkelsystemen van 
TRITEC Benelux B.V. streeft al een kleine tien 
jaar naar een kortere ‘time to market’, een ho- 
gere kwaliteit en een betere productiviteit bij de 
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Het hoe en waarom van hogere 
beschrijvingstalen voor de 
ontwikkeling van elektronica 


1.1 Algemene inleiding 


Het gebruik van hogere beschrijvingstalen zoals VHDL 
wordt steeds populairder. Niet alleen grote multi-nationals 
gebruiken deze krachtige ontwerptechniek maar ook het 
midden en klein bedrijf is succesvol met VHDL. Na een korte 
inleiding van de taal VHDL vindt u een praktijkvoorbeeld van 
een “midden en klein bedrijf” dat door de invoering van 
VHDL uiterst succesvol in zeer korte tijd een FPGA reali- 
seerde. De inleiding van de taal VHDL is afkomstig uit het 
boek “VHDL ‘87/93 en voorbeelden” van Bert Molenkamp. In 
dit boek vindt u een complete beschrijving van de VHDL 
beschrijvingstaal. Het boek is bedoeld voor ontwerpers van 
digitale systemen met programmeervaardigheden. Zowel de 
“oude” VHDL standaard Std. 1076-1987 als de huidige stan- 
daard Std. 1076-1993 wordt erin bescheven. De ‘oude’ stan- 
daard wordt nog nadrukkelijk behandeld, omdat veel van de 
huidige EDA omgevingen nog niet de nieuwe standaard 


ondersteunen. 
1.2 Inleiding VHDL 


Na de ratificatie door de IEEE van de hardware 
beschrijvingstaal VHDL Std 1076-1987 heeft het 
gebruik ervan een enorme vlucht genomen in 
de industrie. IEEE standaarden moeten mini- 
maal om de vijf jaar opnieuw geratificeerd wor- 
den. Inmiddels is de standaard dan ook vervan- 
gen door de Std 1076-1993. Beide worden ook 
vaak aangeduid met VHDL’87 en VHDL'93, de 
laatste soms ook wel met VHDL'92. Dit is het 
oorspronkelijk geplande jaar van de nieuwe 
standaard. Voor alle duidelijkheid er is slechts 
één VHDL standaard namelijk de meest recente 
VHDL 1076-1993. Een subset van de VHDL be- 
schrijvingen is ook synthetiseerbaar. Synthese 
aspecten maken echter geen deel uit van de 
VHDL standaard. Helaas beperken nog veel ge- 
bruikers van VHDL zich tot de subset van VHDL 
welke synthetiseerbaar is door haar/zijn syn- 
these-tool en gaan daarbij voorbij aan de kracht 
van VHDL als specificatietaal van het nog te ont- 
werpen systeem. 

Binnen de IEEE bestaan een aantal werkgroe- 
pen, die gecoördineerd worden door de DASC 
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(Design Automations Standards Committee), 
actief met nauw verwante onderwerpen, o.a. 
“VHDL Analoge Extention Working Group” en 
de “VHDL Synthesis Package Working Group”. 
De “VHDL Synthesis Package Working Group” 
moet een einde maken aan de wildgroei op het 
gebied van synthese van VHDL. Elk synthese 
systeem gebruikt zijn eigen interpretatie en type- 
ring voor bit vectoren en de operaties die hierop 
gebaseerd zijn, waardoor er nauwelijks sprake 
is van portabiliteit tussen de verschillende syn- 
these systemen. Een tweetal packages zullen 
worden afgeleverd, één is gebaseerd op het type 
bit (package numeric_bit) en de andere gaat uit 
van de IEEE package std_logic_1164 (package 
numeric_std). Beide packages zullen naar ver- 
wachting in het voorjaar van 1996 een IEEE 
standaard zijn. De “Verilog Analysis and 
Standardization Working Group” kan in zekere 
zin gezien worden als een concurrent van VHDL. 
De basis van Verilog is in de wintermaanden 
van 1983-1984 gelegd door Phil Moorby en op 
de EDA markt gebracht in 1985 door Cadence 
Design Systems. In 1990 zijn de rechten public 
domain geworden en sindsdien heeft de onaf- 


hankelijke Open Verilog International (OVI) 
groep er bekendheid aan gegeven. Nu Verilog 
ook een IEEE standaard gaat worden ligt het 
voor de hand dat beide hardware beschrijving- 
stalen naast elkaar gebruikt zullen gaan wor- 
den. Naast elkaar omdat de beide talen niet he- 
lemaal hetzelfde doel hebben. Verilog is bedoeld 
vanaf RTL-niveau (Register Transfer Level) tot 
en met de realisatie terwijl VHDL bedoeld is 
vanaf specificatie tot aan de realisatie. Veel EDA 
omgevingen zijn al druk bezig met de voorbe- 
reidingen voor de co-simulatie van VHDL en 
Verilog beschrijvingen, immers het ligt immers 
voor de hand dat op een hoog niveau in VHDL 
wordt ontworpen terwijl de realisatie in Verilog 
is beschreven. Janick Bergeron heeft een ver- 
gelijking gemaakt tussen VHDL en Verilog met 
betrekking tot de simulatiesnelheid en het 
modeleren. 

In de VHDL standaard is niet aangegeven op 
welke wijze ASIC bibliotheken met al hun 
timingsaspecten beschreven moeten zijn. In mei 
1992 werd tijdens de VHDL International User's 
Forum in Scottsdale besloten dit probleem op 
te pakken. Uitgangspunt hierbij was het gebruik 


35 








THEMA: Electronic Design Automation 





switch gate RTL behavioural system 
Modelering 


maken van het SDF (standard delay format), 
welke ook bij Verilog wordt gebruikt, en het ge- 
bruik maken van de al ontwikkelde Std_timing 
package van de VHDL Technology Group en de 
technieken van “Ryan & Ryan”. Verder moest 
voor een groot draagvlag worden gezorgd bij 
de industrie. 

Dit initiatief kreeg dan ook de naam 
VITAL: VHDL Initiative Towards ASIC 
Libraries. In maart 1994 kwam de “VITAL 
2.2b Model Development Specification” 
uit en momenteel wordt al druk gewerkt 
aan VITAL 3.0 dit zal een IEEE standaard 
worden. PAR 1076.4 werkt aan deze 
standaard. In VITAL 2.2b wordt onder 
andere een tweetal packages beschre- 
ven, VITAL_Timing en VITAL_Primitives, 
waarin respectievelijk een groot aantal 
timing procedures zijn beschreven en 
primitieve operaties op bit niveau zijn be- 
schreven. Met daaraan voor de EDA 
tools de uitdaging de package body's zo 
te implementeren dat de simulaties snel zijn. Ver- 
der is er een document beschreven waaraan de 
gebruiker zich moet houden. Dit document en 
de packages zijn via ftp te verkrijgen op adres 
“vhdl.org”. Een consequentie van het gebruik 
van VITAL is ook aangegeven in figuur 1. 


Eigenschappen van VHDL 
VHDL heeft een groot aantal aantrekkelijke ei- 
genschappen: 

Hiërachie wordt ondersteund. 

De gebruiker is vrij om haar/zijn eigen ontwerp- 
methode te gebruiken: top-down, bottom-up, 
etc. 

Technologie onafhankelijk. Dit betekent concreet 
dat een ontwerp van enkele jaren geleden 
zonder problemen hergebruikt kan worden in 
een andere technologie. 

Ondersteuning van verschillende beschrijvings- 
sstijlen, zoals een finite state machine, een 
algoritme, boleaanse vergelijkingen etc. 

“Second-sourcing” eenvoudiger. Aangezien de 
taal EDA Tool onafhankelijk is kan zonder veel 
problemen worden omgeschakeld naar een 
andere omgeving. Belangrijk is het dat ook 
de testomgeving in VHDL is beschreven. Hier- 
voor kan bijvoorbeeld gebruik worden ge- 
maakt van WAVES. 

Verhoging van het abstractieniveau waardoor 
een betere beheersing van de complexiteit 
mogelijk is. Verder kunnen details aan de syn- 
these-tools worden overgelaten. 

Het vroegtijdig opsporen van fouten doordat de 
specificatie al te simuleren is en elke ontwerp- 
stap tegen de simulatie is te testen. 

Large Scale Integration (LSI) modelering is een- 
voudig door het gebruik van ‘componenten’, 
‘functies’, ‘procedures’ en ‘packages’. 

VHDL legt geen beperking op aan de grootte 
van het ontwerp. 

“Test benches’ kunnen in dezelfde taal worden 
beschreven en zijn dus overdraagbaar. 

Dankzij de ‘generics’ en ‘attributes’ is backan- 
notation eenvoudig. Hiervan wordt ook ge- 
bruik gemaakt in VITAL. 

VHDL is een sterk getypeerde taal. Nieuwe data- 

types zijn door de gebruiker zelf te definiéren. 


3.1.4 Inleiding in de 
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Fig. 1 Vergelijking 
tussen Verilog en 
VHDL. 


switch gate 


RTL behavioural system 
Simulatie 


beschrijvingstaal VHDL 


Hoewel VHDL geen imperatieve taal is lijkt 
de syntax van de nog te behandelen proces- 
sen veel op die van sterk getypeerde impe- 
ratieve talen, zoals MODULA-2. In de voor- 
beelden zijn de gereserveerde woorden van 
de taal dik gedrukt weergegeven en in de 
ASCII files worden hoofdletters gebruikt. 





VHDL maakt geen onderscheid tussen 
kleine en hoofdletters. 

Als eerste zal de kern van de taal wor- 
den besproken: communicerende pro- 
cessen. Hierbij wordt ook aangegeven 
hoe deze processen gesimuleerd wor- 
den. Vervolgens wordt een summiere 
inleiding gegeven in de taal- 
constructies. 


1.4.1 Communicerende 


processen 

Hardware kan worden beschouwd als 
een verzameling van parallelle proces- 
sen die met elkaar communiceren. Elk 
proces berekent continu op basis van 
zijn ingangssignalen de daarbij beho- 
rende uitgangssignalen. In een nor 
poort vindt als het ware continu een 
berekening plaatst, ook al zijn de im 
ingangssignalen stabiel. Voor het simu- 

leren van een nor poort is het echter in2 
voldoende om alleen de veranderingen 

door te rekenen (figuur 3). Dus wanneer een 
ingangssignaal verandert, moet een nieuw 
uitgangssignaal worden berekend. Dit 
simulatiemodel, dat ook in VHDL wordt ge- 
bruikt, noemt men event-driven simulation. 


begin 


Figuur 3 geeft een VHDL beschrijving van een 
nor poort. Deze beschrijving bestaat uit twee 
delen: de entity en de ARCHITECTURE. 

De entity geeft de naam van het component 
en wat de in- en uitgangssignalen zijn. Bij 
deze signalen moet ook het type worden op- 
gegeven. In dit voorbeeld zijn beide ingang- 
signalen en het uitgangsignaal van het type 
bit. Dit type is een standaard type van VHDL 
en is gedefinieerd als een enumeratie: type 
bit is (0’,’1');. In de entity-beschrijving kan ook 
nog statische informatie worden opgenomen 
middels een generic statement. In dit voor- 
beeld geeft het aan dat de poort default een 
vertraging heeft van 10 ns. Beschouw de 
generic voorlopig als een constante. De 
generic en de port statements mogen ach- 
terwege blijven. 

De architecture bepaalt het gedrag tussen de 
in- en uitgangssignalen in dit voorbeeld door 


entity nor_gate is 


middel van een procesbeschrijving. Een 
procesbeschrijving is een sequentiéle beschrij- 
ving te vergelijken met die van de imperatieve 
talen. Voor de nor poort kan het gedrag door 
middel van een eenvoudige procesbeschrijving 
worden bepaald. Deze geeft aan dat het 
uitgangssignaal our1 de logische nor is van in1 
en n2 en vervolgens wordt er gewacht op een 
verandering van in1 en/of n2. Na een verande- 
ring van een ingangssignaal vervolgt de execu- 
tie van het proces zich weer na de wait state- 
ment en aan het einde gekomen van de proces- 
beschrijving vervolgt de executie zich aan het 
begin. 


Figuur 4 geeft een VHDL beschrijving van een 
sr-latch. Tevens is in de entity-beschrijving com- 
mentaar opgenomen, door gebruik te maken van 
de ‘--’. Documenteren is een belangrijk onder- 
deel van het ontwerpproces. Wat een entity be- 


Fig. 2 
Simulatieresultaten 
van de NOR-poort. 






generic (delay : time := 10 ns); 
port (inl, in2 in bit; 
out1 out bit); 


end nor_gate; 
architecture gedrag of nor_gate is 


nor_gate:process 
begin 
outi. <= inl nor in2 after delay; 
wait on inl, 
end process; 
end gedrag; 


in2; 


71 outi 


figuur 3 VHDL beschrijving 
van een nor poort. 


hoord te doen staat altijd als commentaar in de 
entity en hoe dat wordt verkregen als commen- 
taar in de architecture. 

Elke nor poort is beschreven met een proces- 
beschrijving. De volgorde waarin de beide pro- 
cessen zijn beschreven is niet belangrijk. Com- 
municatie tussen beide processen kan alleen 
plaats vinden door middel van signalen. Hoe 
lokalesignalen worden gedeclareerd is ook in 
het voorbeeld aangegeven, deze declaraties be- 
vinden zich tussen de gereserveerde woorden 
ARCHITECTURE en BEGIN. De signalen ai en al_NoT 
zijn in deze beschrijving lokaal. Verder is aan- 
gegeven dat het signaal ai_not tijdens het 
initialiseren de waarde ‘1’ krijgt. Indien een sig- 
naal niet expliciet geïnitialiseerd wordt krijgt het 
de meest linkse waarde van het bereik van het 
signaal. Signaal ai wordt niet expliciet 
geïnitialiseerd, daarom krijgt deze tijdens het 
initialiseren de waarde ‘O’ ( type bit is (‘0’,’1'); ). 
Ook de ingangssignalen hebben een initiéle 
waarde. De ingangen s en R zijn beide ‘0’ aange- 
zien ze van het type bit zijn. 


Elke VHDL beschrijving wordt intern vertaald 


naar communicerende processen. In figuur 4 zijn 
de componenten NorR_GATE1 en NOR_GATE2 expli- 
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entity sr_latch is 


generic (delay : time := 10 ns); 
port (s,r in bit; 
q,q_not out bit); 
-- description of an sr_latch. 
=- s € | g gmot 
-- 0 0 | unchanged 
a g a | ~ i 
-= teu e ø 
-- 1 aa f og 
end sr_latch; 


architecture gedrag of sr _ latch is 


-- architecture-beschrijving gebruikmakend 


~-van twee processen. 
signal qi > Bate; 
signal gi not : bit := 
begin 


ti” 











nor_gatel:process 
begin 


wait on r, qi_not; 
end process; 


nor_gate2:process 
begin 


wait on s, qi; 
end process; 


ee dy 


q not <= qi_not; 


end gedrag; 








ciet be- 
schreven. 
Deze 
twee pro- 
cessen 
rallel uit- 


worden pa- 
gevoerd. Explicieteprocesbeschrijvingen zijn ge- 
koppeld aan de gereserveerde woorden PROCESS 
en END PROCESS. 


Een complex digitaal systeem beschrijven met 
and’s, or’s en inverters is niet gebruikelijk. In een 
dergelijk systeem kan meestal weer onder- 
scheid gemaakt worden tussen de verschillende 
functionele blokken, zoals alu’s (arithmetic logic 
units), geheugens etc. Niet alleen tijdens het be- 
schrijven maar ook tijdens het ontwerpen van 
een digitaal systeem is het belangrijk dat gelei- 
delijk aan meer detail kan worden toegevoegd. 
Door middel van een struktuurbeschrijving kan 
hiérarchie in het ontwerp worden aangebracht. 
Een struktuurbeschrijving in VHDL is een op- 
somming van componenten en hoe deze met 
elkaar verbonden zijn. 


1.4.2 Korte samenvatting 
beschrijvingstaal VHDL 


Een beschrijving van hardware bestaat uit een 

entity en één of meer architectures. 

De entity legt de communicatie met de omge- 
ving vast, ook kan hierin een generic worden 
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qi <= r nor qi not after delay; 


qi not <= s nor qi after delay; 





figuur 4 Een sr-latch. 


opgenomen. In de entity-be- 
schrijving wordt commentaar 
opgenomen wat de functie 
van de beschreven hardware 
is. 
De architecture legt het ge- 
drag vast van hardware. Als 
commentaar wordt globaal 
aangegeven hoe de ge- 
wenste functie is vervuld. 
VHDL is gebaseerd op com- 
municerende processen. 
Deze processen zijn impli- 
ciet of expliciet aanwezig. De 
volgorde waarin impliciete of 
expliciete processen zijn be- 
schreven is niet belangrijk, 
de volgorde van de 
statements binnen een expli- 
ciete procesbeschrijving wel. 
VHDL heeft een drietal ob- 
jecten: signalen, variabelen 
enconstanten. Communica- 
tie tussen de processen kan 
alleen plaats vinden door 
middel van signalen. Alleen 
binnen een proces- 
beschrijving, functies en pro- 
cedures mogen variabelen 
worden gebruikt. 
Entiteiten kunnen als onder- 
deel van een andere 
architecture-beschrijving 
worden gebruikt door com- 
ponenten te declareren en 
dit vervolgens door middel 
van een configuratie-speci- 
ficatie te koppelen aan de 
entiteit. 
Formele en actuele parame- 
ters worden gekoppeld door 
een positionele koppeling - 
een actuele parameter staat 
op de plaats van de formele 
parameter waarmee het ge- 
koppeld moet worden - of 
expliciet door de formele en 
actuele parameters te kop- 
pelen m.b.v. de ‘=>’. Een 
combinatie is mogelijk, mits 
eerst de positionele koppe- 
ling is aangegeven. 

Variabelen en signalen wor- 

den default geinitialiseerd 
met de meest linkse waarde van het desbe- 
treffende type. 

Functies leveren slechts één resultaat op, aan 
een variabele of signaal. Procedures kunnen 
meer resultaten opleveren maar default alleen 
maar aan variabelen. In een package en 
package body kunnen types, functies, proce- 
dures, componenten e.d. worden 
gedeclareerd waarvan door middel van een 
‘use-clause’ gebruik gemaakt kan worden. 
Door middel van de mode ‘in’, ‘out’ en ‘inout’ 
wordt aangegeven of er resp. spra- 
ke is van een in, uit of bidirectionele 
parameter is. Tevens zijn er nog de 
modes ‘buffer’ en ‘linkage’. De laat- 
ste mode wordt zelden gebruikt. 


1.4 Van een VHDL 
beschrijving naar een 
realisatie 


Het ontwerpen van digitale systemen 
met behulp van VHDL is mogelijk van 
de specificatie tot en met een imple- 
mentatie op logisch niveau. De reali- 
satie zelf wordt in het algemeen niet 
in VHDL beschreven. Hiervoor waren ten tijde 
van de ontwikkeling van VHDL in 1980 reeds 
voldoende hulpmiddelen aanwezig. Na een aan- 
tal ontwerpstappen uitgevoerd te hebben in 
VHDL blijft er een beschrijving over die door een 


commerciële synthese-tool gerealiseerd kan 
worden. De VHDL beschrijving wordt omgezet 
in een realisatie (full custom, gate array, 
programmeerbare logica, etc.). De commerciële 
synthese-tools zijn grofweg te verdelen in twee 
groepen: 

logische synthese 

hoog niveau synthese 


Bij een synthese systeem dat uitgaat van logi- 
sche synthese wordt vaak een één op één af- 
beelding van VHDL naar een technologie uitge- 
voerd met een beperkt aantal combinatorische 
minimalisaties. Dit betekent dat de VHDL be- 
schrijving al zoveel detail moet bevatten dat voor 
het synthetiseren al in grote lijn bekend is hoe- 
veel registers e.d. gebruikt gaan worden. 
Synthese systemen die hoog niveau synthese 
uitvoeren zijn in staat ook een aantal ontwerp- 
beslissingen op een hoger abstraktie niveau 
mee te nemen. Zo wordt bijvoorbeeld nagegaan 
of meerdere optellers zoals die beschreven zijn 
in de VHDL beschrijving niet gecombineerd kun- 
nen worden, uiteraard zonder het gewenste ge- 
drag te veranderen. Ook kunnen beschrijvingen 
waarin de toestanden impliciet aanwezig zijn ge- 
realiseerd worden. 

Vaak kan een ontwerp ingedeeld worden in een 
data-pad en een besturing voor dit data-pad. De 
besturing kan vaak beschreven worden in de 
vorm van een toestandsmachine, terwijl in een 
data-pad vaak weer componenten alsoptellers, 
multiplexers e.d. voorkomen. Er zijn dan ook syn- 
these systemen die verschillende algoritmen ge- 
bruiken voor het synthetiseren van een data-pad 
en een besturing. 

Inmiddels zal het duidelijk zijn dat er veel alter- 
natieve VHDL beschrijvingen mogelijk zijn om 
hetzelfde gedrag te beschrijven. Synthese sys- 
temen ondersteunen echter slechts een subset 
van de mogelijkheden van VHDL en, helaas, niet 
dezelfde subset. 


1.5.1 Wat is niet 
synthetiseerbaar? 


In veel hardware beschrijvingstalen zijn alle con- 
structies af te beelden op hardware. Het is de 
intentie van VHDL dat ook een specificatie moet 
kunnen worden beschreven. Taalconstructies die 
in een dergelijke beschrijving worden gebruikt 
hoeven niet synthetiseerbaar te zijn. Nagenoeg 
alle synthese systemen hebben geheel of ge- 
deeltelijk problemen met: 

expliciet opgegeven vertragingstijden 
asynchrone beschrijvingen 

wait statements 

dynamische strukturen, recursie, loops en files 
typering voor signalen 

het event-driven simulatiemodel 


1.5.2 ‘Hoog niveau’ 
synthese 


In de vorige paragraaf is aangegeven van wat 





figuur 5 FPGA 
design flow 3T. 
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wel en niet synthetiseerbaar is. Aan de hand 
hiervan kan bepaald worden tot hoever je een 
beschrijving in VHDL moet ontwerpen voordat 
het betrouwbaar gesynthetiseerd kan worden. 
Er wordt getracht steeds betere synthese sys- 
temen te ontwikkelen waardoor de ontwerper 
steeds minder detail in de VHDL beschrijving 
hoeft aan te geven, waardoor de beschrijving 
vaak ook beter te begrijpen blijft. 


1.6 Samenvatting 


Niet alle VHDL beschrijvingen zijn syntheti- 
seerbaar. In het algemeen geldt dat alle realisa- 
ties met simulatietijd niet te realiseren zijn. Dus 
expliciet opgegeven vertragingstijden worden 
genegeerd, ook attributen welke gerelateerd zijn 
aan de tijd worden niet ondersteund. Realisatie 
van dynamische strukturen en recursieve 
funkties is eveneens niet mogelijk. Verder wordt 
het event-driven simulatiemodel niet in alle op- 
zichten gesynthetiseerd. 

De meeste synthese systemen gaan uit van syn- 
chrone ontwerpen. In dat geval is het resultaat 
meestal ‘correct by construction’. Verificatie, bij- 
voorbeeld door middel van simulatie, van het ge- 
realiseerde tegen het gewenste gedrag blijft al- 
tijd wenselijk omdat de synthese software nooit 
foutloos is. Afhankelijk van het soort beschrij- 
ving (data-pad of besturing) worden soms ook 
verschillende algoritmen gebruikt om een opti- 
maal resultaat te krijgen. Of snelheid of opper- 
vlak belangrijk is kan de synthese-tool niet we- 
ten, daarom kan dit in de tool worden aangege- 
ven. 

EDA systemen hebben naast de standaard 
package vaak een groot aantal extra funkties 
en procedures waardoor beschrijvingen eenvou- 
diger worden. Deze funkties en procedures wor- 
den meestal ook door een synthese-tool onder- 
steund. 


1.6 Praktijk voorbeeld: 3T 
uiterst succesvol in hoog 


niveau FPGA ontwerp 

Het bedrijf 3T B.V. in Enschede heeft onlangs 
een FPGA (Field Programmable Gate Array) 
ontwerp gerealiseerd binnen 2 maanden, vanaf 
specificatie tot realisatie. En dat zonder dat men 
praktische ervaring had van de gebruikte top- 
down ontwerp methode en de toegepaste 
tooling! 

3T is een ingenieursbureau dat in 1988 is ont- 
staan uit het Centrum voor Micro Elektronica 
(CME). 3T heeft momenteel meer dan 30 me- 
dewerkers en de hoofdactiviteit is ontwikkeling 
en produktie van micro-elektronica op klanten- 
specificatie. Bij de ontwikkeling wordt de struc- 
turele specificatie methode Yourdon toegepast. 


In december 1995 ontstond de wens om een 
FPGAte ontwikkelen. Deze zou dienst doen als 
prototype, in de uiteindelijke produktie zal het 
ontwerp in een ASIC worden geïmplementeerd. 
Het was daarom zaak om hierbij de ontwikke- 
ling van de FPGA rekening te houden, zodat het 
FPGA-ontwerp eenvoudig naar een ASIC kon 
worden omgezet. 

Om aan deze eisen te voldoen, heeft TRANS- 
FER EDS samen met 3T hiervoor het ontwerp- 
traject opgesteld. Het gebruik van een techno- 
logie onafhankelijke beschrijvingstaal moest 
hiervoor de basis zijn. Het uitgangspunt is van 
het begin af aan een VHDL beschrijving ge- 
weest, omdat deze IEEE beschrijvingstaal we- 
reldwijd ondersteund wordt en daardoor voor 
zowel de ontwikkeling van het FPGA prototype 
als voor de uiteindelijke ASIC gebruikt kan- 
worden. Het VHDL ontwerp kan dus voor de uit- 
eindelijke produktie worden overgedragen aan 
de ASIC ontwikkelaar. 


Bij 3T was nog weinig praktische ervaring met 
VHDL aanwezig. Omdat het project onder tijds- 
druk stond en een universele aanpak met VHDL 
een must was, is er uiteindelijk voor gekozen 
om het complete ontwerp grafisch in te voeren 
en te simuleren. Vervolgens wordt er automa- 
tisch VHDL gegenereerd en deze VHDL file 
wordt geïmplementeerd in een FPGA. Het com- 
plete ontwerp-traject is weergegeven in de fi- 
guur 5. Uit deze figuur zijn omwille van de dui- 
delijkheid de verificatie stappen tussen alle fa- 
sen weggelaten. 

Voor de grafische invoer van de toestands- 
diagrammen werd gebruikt gemaakt van de tool 
ExpressV-HDL van i-Logix. Door deze tool te ge- 
bruiken is het mogelijk om direct het ontwerp te 
simuleren. Daarnaast zorgt ExpressV-HDL voor 
consistentie van het systeem. Het invoeren en 
simuleren van het ontwerp heeft voor veel dui- 
delijkheid gezorgd. “Je kunt je zo op het gedrag 
van je ontwerp richten en niet op hoe de scha- 
keling uiteindelijk gerealiseerd moet worden”, al- 
dus Norbert Beltman en Peter Orth van ST. 


Nadat de simulatie resultaten waren geverifieerd 
en correct bevonden, genereerde de ExpressV- 
HDL tool van i-Logix automatisch de syntheti- 
seerbare VHDL code. Deze code is met behulp 
de FPGA Compiler van Synopsys gesyntheti- 
seerd naar een Actel A1020 FPGA (2000 gates, 
547 logische modules). De kracht van FPGA 
Compiler van Synopsys bleek onder andere uit 
het volgende. Een aantal tellers die in ExpressV- 
HDL gespecificeerd waren, bleek niet noodza- 
kelijk. De FPGA Compiler optimaliseerde het uit- 
eindelijke resultaat en verwijderde een aantal 
niet gebruikte logische delen. Dit leverde een 
aanzienlijke besparing op qua aantal gebruikte 
logische modules. 


Eris voor een Actel FPGA gekozen omdat deze 
door zijn anti-fuse techniek een voorspelbaar 
gedrag heeft en te verkrijgen is in vele soorten 
behuizingen en groottes. De Actel FPGA archi- 
tectuur heeft nog een voordeel omdat er is geen 
extra EPROM nodig is om de configuratie op te 
slaan. Dit was van doorslaggevend belang om- 
dat hiervoor geen ruimte was op het printed cir- 
cuit board. Een 44-pins PLCC behuizing vol- 
deed. 


De eerste synthese slag leverde een te groot 
ontwerp op. Dit werd met name veroorzaakt door 
de vele tellers in het ontwerp. Na een extra 
optimalisatie slag is het uiteindelijk gelukt de 
A1020 FPGA voor 100% te vullen, alle 547 lo- 
gische modules worden gebruikt! Dit grote ge- 
tal baarde ons in eerste instantie nogal wat zor- 
gen. Er werd namelijk gedacht dat een ontwerp 
met deze bezettingsgraad niet meer in de chip 
te plaatsen was. De pin-layout van de FPGA was 
namelijk al vastgesteld omdat andere ontwer- 
pers het uiteindelijke bord al hadden ontworpen. 
De “place and route” leverde echter totaal geen 
problemen op: de Actel ALS Designer 3.0 soft- 
ware klaarde de klus in minder dan 5 minuten. 
Dit onderstreept nog maar eens weer de enorm 
flexibele “routability” van de Actel architectuur 
als gevolg van de kleine “grain”-structuur van 
de Actel anti-fuse technologie. Het ontwerp 
haalde een maximale kloksnelheidvan ruim 8 
MHz hetgeen ruim voldoende was voor deze 
applicatie. Hierbij kan nog worden opgemerkt 
dat deze snelheid alleen voor het reset-signaal 
geldt en dat we verder geen optimalisatie heb- 
ben gedaan naar snelheid. Van de A1020 FPGA 
is de standaard speedgrade gebruikt. 


ST heeft hiermee samen met TRANSFER EDS 
weer bewezen dat een hoog niveau FPGA ont- 
werp-traject in relatief korte tijd zeer goed is uit 
te voeren. En dat deze technologie niet alleen 
is voorbehouden aan grote multi-nationals met 
hoge R&D budgetten. Ook het midden en klein 
bedrijf kan uitermate succesvol zijn met top- 
down ontwerp methodiek. Tevens werd met dit 
project weer eens aangetoond dat alleen de be- 
schikbaarheid van de juiste tooling niet automa- 
tisch tot de gewenste resultaten leidt. Intensieve 
begeleiding van de leverancier is van groot be- 
lang om de inleer-fase zo kort en efficiënt mo- 
gelijk te houden. 


Erik Nijboer TRANSFER Electronic 
Design Support 

Bert Molenkamp, Universiteit Twente 
Auke Vleerstraat, 7521 PG Enschede 
Tel. 053-4330336, fax 053-4340336 
email info @transfer.nl, http:// 
www.xxlink.nl/transfer 





VHDL, de standaard in hardware 
beschrijvingen 


Bij veel grote en specialistische elektrotechnische bedrijven is een hardware beschrijving- 
staal (Hardware Description Language, HDL) goed ingeburgerd. Veel van deze bedrijven 
gebruiken VHDL, of zullen dit op korte termijn gaan toepassen. VHDL staat voor Very High 
Speed Integrated Circuit Hardware Description Language. Een Amerikaans onderzoek laat 
zien dat het merendeel van de IC ontwerpers een HDL gebruikt en op korte termijn zal VHDL 
de meest toegepaste HDL zijn. Het lijkt erop dat VHDL de nieuwe standaard wordt voor het 
beschrijven van hardware. Dit artikel gaat nader in op de achtergronden van deze trend en 
de gevolgen voor kleine en middelgrote bedrijven. 
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2.2 Beheersen van 


complexiteit 

Complexe elektronische systemen kunnen be- 
ter met behulp van een HDL ontwikkeld worden 
dan met schematische invoer. Bij een HDL wordt 
de architectuur en het gedrag van een schake- 
ling beschreven op een computerprogramma- 
achtige manier. Dit in tegenstelling tot poort- 
niveau bij schematische invoer. Grote delen van 
een elektronisch schema kunnen met HDL 
statements beschreven worden. De correcte 
werking van een HDL ontwerp kan met behulp 
van een simulator worden aangetoond en door 
middel van synthese kan deze beschrijving au- 
tomatisch vertaald worden naar een elektronisch 
circuit op poortniveau. Met behulp van deze ont- 
werp-methodiek is de complexiteit van grote 
systemen beter beheersbaar en wordt de ont- 
werper produktiever en waarschijnlijk ook crea- 
tiever. 


2.3 Inwerktijd 


De elektronica branche is een zeer dynamische 
wereld. De ontwerpers worden overspoeld met 
nieuwe realisatietechnieken en ontwikkel- 
gereedschappen met ieder hun eigen HDL 
invoertaal. Er zijn op het ogenblik enkele tien- 
tallen HDL’s op de markt. Het overstappen van 
de ene HDL op de andere is een kostbare en 
tijdrovende zaak. De ontwerper zal zich ten eer- 
ste moeten inwerken in de nieuwe taal en ver- 
volgens zullen de ontwerp-databases moeten 
worden vertaald. Er wordt veel waarde gehecht 
aan een standaard taal, die gebruikt kan wor- 
den voor verschillende ontwikkel- 
gereedschappen. 


2.4 Ontstaan VHDL 
standaard 


Veel van de elektronische standaards zijn af- 
komstig uit Amerika. Het Amerikaanse Ministe- 
rie van Defensie (DOD) besteedt veel geld aan 
research, ontwikkelingen en standaardisatie. 
Veel werk wordt daarbij uitbesteed aan 
commercikle ontwikkelbedrijven. Het nadeel 
hierbij is dat elk bedrijf zijn eigen ontwikkel- 
methodiek en ontwikkeltools gebruikt, zodat 
deelontwerpen moeilijk kunnen worden her- 
gebruikt en worden onderhouden. Dit alles 
maakte het noodzakelijk om een standaard taal 
te ontwikkelen. Het VHDL programma werd in 
1981 voorgesteld. Met VHDL is het mogelijk om 
elektronische circuits onafhankelijk van de 
ontwerptools en technologie te kunnen beschrij- 
ven. Het grote voordeel hierbij is dat ontwerpen 
overdraagbaar zijn en dat deel ontwerpen kun- 
nen worden hergebruikt zodat het relatief een- 


voudig is om een meer geavanceerdere reali- 
satie techniek te gaan gebruiken. In 1987 werd 
VHDL een internationale standaard (IEEE 
1076). Het grote voordeel van deze standaard 
is dat verschillende groepen de taal- 
onderhouden en verder ontwikkelen met 

een goede inspraak procedure. De taal wordt 
onafhankelijk van commerciële producenten 
verder ontwikkeld. Zo kwam in 1992 een stan- 
daard uit die de logische niveaus van een digitaal 
signaal definieert (Standard Logic Value, IEEE 
1164). Verdere ontwikkelingen worden en zijn 
gedaan op het gebied van analoge technieken, 
synthese, timing en back-annotation. 


2.5 Commerciële VHDL 
produkten 


Commerciële bedrijven kregen grote interesse 
in de nieuw ontwikkelde VHDL taal. Veel produ- 
centen van ontwikkelgereedschappen gingen 
eigen VHDL tools ontwikkelen en voegde VHDL 
interfaces toe aan bestaande tools. Momenteel 
heeft bijna elke tool een VHDL interface en zijn 
er al speciale VHDL ontwikkelomgevingen voor 
een personal computer te koop voor enkele dui- 
zenden guldens. 

Door het grote aanbod van VHDL tools is het 
niet moeilijk meer om een compleet VHDL ont- 
werp traject op te zetten. Het gebruik van VHDL 
biedt flexibiliteit. Nieuwe tools kunnen eenvou- 
dig worden toegevoegd. Een groot deel van het 
ontwerp-traject is onafhankelijk van de uitein- 
delijke realisatietechniek. Aan het eind van het 
ontwikkeltraject bepaalt men met behulp van een 
synthese tool de uiteindelijke realisatie vorm, zo- 
als PLD’s, FPGA’sof een eigen ASIC. 


2.6 Overdraagbare 
specificaties 

Grote complexe systemen kunnen door middel 
van VHDL op architectuur niveau beschreven 
worden. Vervolgens worden de functies van de 
subsystemen, de bijbehorende interfaces en de 
omgeving waarin het elektronische systeem 
moet werken beschreven. Dit heeft als voordeel 
dat het hele systeem en de interactie met de 
omgeving gesimuleerd kan worden. Verder kan 
de ontwikkeling van een deelsysteem eenvou- 
dig uitbesteed worden. 

Met name voor kleine bedrijven heeft dit enorme 
voordelen. Het bedrijf kan zelf de hele specifi- 
catie opstellen van een produkt. Vervolgens kun- 
nen delen van het ontwerp worden uitbesteed 
aan een specialistisch bedrijf die het omzet in 
een optimale realisatievorm (bijvoorbeeld een 
FPGA of ASIC). Kleine bedrijven kunnen hier- 
mee geavanceerde produkten ontwikkelen. Het 


opstellen van een goede gedetailleerde specifi- 
catie is vaak het moeilijkste en meest tijdrovende 
deel van het hele ontwerp-traject. Dit deel kan 
een klein bedrijf zelf uitvoeren zonder veel extra 
investeringen in apparatuur en tools. Alleen het 
bedrijf weet immers de specificatie van het te 
ontwikkelen produkt. 

Aan de andere kant bestaat er een trend dat 
een opdrachtgever steeds meer eisen gaat stel- 
len aan het ontwikkeltraject van een uitvoerder. 
Het Amerikaanse Ministerie van Defensie stelt 
als eis dat alle extern ontwikkelde elektronica 
beschreven moet zijn in VHDL. Steeds meer 
bedrijven nemen deze ontwerp-eis over. 


2.7 Zijn er ook nadelen ? 


Na alle positieve geluiden moeten we ook on- 
derkennen dat er natuurlijk enkele negatieve 
kanten zitten aan het gebruik van VHDL. Zo is 
één van de geclaimde voordelen, dat VHDL mo- 
dellen kunnen worden uitgewisseld. Maar het 
probleem is dat een VHDL model verschillende 
interfaces of inhoud kan hebben, zodat het niet 
mogelijk is om ze rechtstreeks uit te wisselen. 
Bij de producenten van ASIC’s is dit een van de 
grootste problemen. Daarom werken verschil- 
lende groepen aan een standaard voor de me- 
thode van modelleren. Zo werkt bijvoorbeeld de 
VITAL organisatie (VHDL Initiative Toward ASIC 
Libraries) aan standaard ASCI bibliotheken. 


Sommige ontwerpers vinden VHDL omslachtig 
in het gebruik en niet echt geschreven voor hard- 
ware ontwerpers. Daarbij geeft men vaak aan 
dat de VHDL simulators relatief langzaam zijn. 
Deze kritiek zal zeker waar zijn, maar dit weegt 
niet op tegen de voordelen die het gebruik van 
VHDL geeft. 


2.8 Conclusie 

Het belang van VHDL neemt sterk toe. Zoals 
het zich nu laat aanzien begint VHDL de stan- 
daard hardware beschrijvingstaal te worden. 
Steeds meer opdrachtgevers zullen eisen dat 
het ontwikkeltraject plaatsvindt in VHDL. Mid- 
delgrote en kleine bedrijven zullen hierdoor ook 
genoodzaakt zijn om VHDL te gaan gebruiken. 
Voor de ontwerper heeft VHDL veel voordelen. 
Elektronische systemen kunnen op een hoger 
niveau worden beschreven. Verder zijn er veel 
ontwikkelgereedschappen op de markt die een 
VHDL interface hebben. 


Ir. G.J. Kleissen 

Ing. S.W. Hulst 

Centrum voor Micro-Elektronica 
Tel: 0318-580200 





EFFICIENCY WITH VHDL 


How to improve time to market 


VHDL, een andere manier van het omschrijven van 
programmeerbare logica. U zult wel denken, daar hebben 
we al zo veel van! Toch is het belangrijk dat u even tijd 
maakt om dit korte stukje tekst door te lezen. Het gaat na- 
melijk om efficiëntie. Is dat niet iets waar iedereen in geïnte- 


resseerd is? 
3.2 Waarom VHDL ? 


VHDL is benoemd als de (toekomstige) stan- 
daard voor het beschrijven van programmeer- 
bare logica. Het ligt dus in de lijn der verwach- 
ting dat de komende tijd iedere designer die op 
dit gebied actief is in aanraking zal komen met 
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VHDL. Het resultaat hiervan zal zijn dat de com- 
municatie in een projectteam verbetert. Als men 
dezelfde taal spreekt, begrijpt men elkaar beter. 
Dit geldt dus ook voor de communicatie tussen 
designers onderling, ontwikkelaar en gebruiker, 
contractors en verschillende design tools. 

Het maakt overigens niet uit of het design be- 


stemd is voor een Programmable Logic Device 
(PLD), een Complex Programmable Logic De- 
vice (CPLD) of een Field Programmable Gate 
Array (FPGA). VHDL is hardware onafhankelijk. 
Het is dus zeer flexibel. Op het laatste moment 
kunt u nog van device veranderen. 
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3.3 VHDL.......Wat is dat 
eigenlijk ? 

VHDL staat voor “Very high speed integrated 
circuit Hardware Development Language”. VHDL 
is ontstaan in de jaren ’70 uit een ontwikkeling 
van de Amerikaanse defensie. Hier werd een 
taal ontwikkeld om complexe circuits te kunnen 
documenteren, zodat een design van een con- 
tractor door een ander begrepen kon worden. 
Vandaag de dag gaat het gebruik van VHDL wat 
verder dan alleen documenteren. Het kan ge- 
bruikt worden voor het beschrijven, simuleren 
en de synthese van logic designs. Het beschrij- 
ven van de logica gebeurt in de vorm van een 
hogere programmeertaal (voorbeelden volgen). 
Hierdoor is het leesbaar voor mens en machine. 
Uiteraard gaat men er dan wel van uit dat deze 
mensen enige kennis hebben van programmeer- 
talen. Bij het simuleren kunnen we zowel func- 
tionele- als timingsimulatie toepassen. De ti- 
ming-simulatie is vooral bij FPGA's van groot 
belang. Hier heeft de ‘routing’ van het design in 
het device namelijk heel veel invloed op. 
Onder synthese verstaan we het omzetten van 
de beschrijving van een design naar de beschik- 
bare hardware logica. Dit is dus eigenlijk de 
conversieslag van software naar hardware. 


3.4 Hoe werkt VHDL? 


VHDL gaat altijd uit van twee basisblokken, nl. 
de ENTITY en de ARCHITECTURE. De entity 
kunnen we zien als een black-box waar we sig- 
nalen in zien gaan en uit zien komen. We weten 
hier niet wat er met deze signalen gebeurt. Kort 
gezegd praten we hier dus over de I/O definitie 
van een black-box. In de architecture omschrij- 
ven we nu juist het gedrag van de black-box. 
Hier kunnen we met verschillende opdrachten 
(statements) definiëren wat er gebeurt met de 
reeds aangegeven I/O. 


De Entity 


HH O1 
12 Blackbox 02 
13 


Hierboven ziet u een voorbeeld van de blackbox. 
De entity omschrijving die hierbij hoort is als 
volgt: 
entity TEST is 
port (11, 12, 13 : in bit; 
O1, O2 : out bit); 
end TEST; 








U ziet inderdaad een omschrijving van de I/O. 

Wat betekenen nu de gegevens die tussen haak- 

jes staan? We beginnen met de namen van pa- 

rameters, hier 11, 12 en 13. Dan volgen ‘mode’ en 

het ‘type’ van het signaal. Voor de ‘mode’ heb- 

ben we de volgende keuzemogelijkheden: 

* in: de parameter is alleen een ingang 

*out : de parameter is alleen een uitgang 

* in/out : de parameter is zowel in als uitgang 
(bidirectioneel) 

* buffer : de parameter is een uitgang, maar kan 
ook nog intern gebruikt worden 

Hieronder zien we een aantal mogelijke type 

aanduidingen 
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* bit: de parameter is een bit 

* bit vector(3 downto 0): de parameter is een 4 
bits woord 

* x01Z: de parameter kan de waarden don't care, 
0, 1 en tri-state hebben 

* integer: de parameter is een integer 

* boolean: de parameter is true of false 

* enumerated: de parameter kan waarden aan- 
nemen die door de gebruiker zelf opgegeven 
zijn 

Een voorbeeld van het laatste type zou zijn: type 

STATUS is (start, slow, fast, stop). 

Dit is de basis van de entity. We kunnen uiter- 

aard zoveel I/O regels definiëren als nodig zijn 

voor het design. De type declaratie die hier ge- 

geven wordt is erg bindend. Dit kan soms lastig 

zijn omdat je verplicht bent om nauwkeurig en 

eenduidig te werken, maar is dit eigenlijk niet 

juist het voordeel? 


3.4.1 De Architecture 


De Architecture is de omschrijving van het ge- 
drag van de entity. We hebben hier verschillende 
mogelijkheden om het gedrag te omschrijven, 
we kunnen gebruik maken van: 
Behavioral/Structural descriptions 


Bij behavioral descriptions kunnen we gebruik 
maken van abstracte omschrijvingen of van 
boolean equations. Bij een abstracte omschrij- 
ving kunt u denken aan: 

if a = b then state <= state5 


Bij boolean equations denken we aan: 
x <= (a OR b) AND c 


Vooral de abstracte manier van omschrijven is 
heel begrijpelijk. Deze verdient dan ook veelal 
de voorkeur. Vooral bij grotere designs heeft dit 
dan het voordeel dat iemand anders snel inzicht 
heeft in de werking. Bij structural descriptions 
wordt gebruik gemaakt van standaard compo- 
nenten. Deze componenten zijn ook weer op- 
gebouwd uit een entity en architecture structuur. 
Tevens is het mogelijk om meerdere componen- 
ten te combineren. Dit doen we met behulp van 
een package. In de topfile hoeft alleen kenbaar 
gemaakt te worden dat dit package gebruikt 
moet worden. Eigenlijk is het alleen aantrekke- 
lijk deze manier te gebruiken bij grotere designs 
om een opsplitsing te maken. Hierdoor is men 
in staat het design hiërarchisch op te zetten. 
Hieronder een voorbeeld van een twee bits 
comparator: 

xor2 portmap (a,b,i); 

inv portmap (i,c); 


De standaard componenten zijn hier ‘xor2’ en 
‘inv’. Bij deze omschrijving wordt ervan uitge- 
gaan dat de componenten reeds gedefinieerd 
zijn. Indien een comparator voor een byte ge- 
maakt moet worden, wordt de omschrijving een 
stuk uitgebreider. Per bit moet een vergelijk ge- 
maakt worden waarna het resultaat getotali- 
seerd wordt. In de praktijk zal veelal de combi- 
natie behavioral met structural descriptions voor- 
komen. 


3.4.2 Sequential en 


Concurrent statements 


Binnen een architecture kunnen de opdrachten 
achtereenvolgens uitgevoerd worden 
(sequential) of gelijktijdig (concurrent). De voor- 
beelden die tot nu toe gegeven zijn, zijn allen 
concurrent. Indien sequential statements ge- 
wenst zijn moeten we gebruik gaan maken van 
de ‘PROCESS’ structuur. 

Deze structuur ziet er als volgt uit: 
PROCESS(clk, rst) 

BEGIN 


END PROCESS; 


Opdrachten in PROCESS worden sequentieel 
uitgevoerd. Pas bij het END PROCESS state- 
ment worden de nieuwe waarden toegekend aan 
de variabelen. De laatst toegekende waarde telt. 
De parameters tussen haakjes is de zoge- 
naamde ‘sensitivity list. PROCESS wordt pas 
actief indien een van deze parameters van 
waarde verandert. Het is mogelijk om verschil- 
lende processen in een architecture op te ne- 
men. Deze worden dan weer concurrent t.o.v. 
elkaar uitgevoerd. De eerste aanzet tot VHDL is 
hiermee gegeven. Hieronder een voorbeeld van 
een design voor een 4- bits counter in VHDL. 


entity TEL is port( 
count : buffer bit_vector(3 downto 0); 
clk, rst : in bit); 

end TEL; 


architecture ARCHTEL of TEL is 
process(clk) 


begin 
if (clk'event and clk="1") then 
if rst = ‘1’ then count <=’0000'; 
else count <= count + ‘1’; 
end if; 
end process; 
end ARCHTEL; 


Uiteraard is het niet mogelijk alle details van 
VHDL in zo’n kort artikel te noemen. Het ging 
hier om een introductie van de mogelijkheden. 
Ter afsluiting nog een aantal kernpunten met de 
voordelen voor de gebruiker: 


Eigenschappen VHDL 
Voordeel de gebruiker: 
* Gestandaardiseerde taal voor hardware 
* Algemene bekendheid, makkelijker te 
beschrijvingen leren 
* Geschikt voor beschrijving, simulatie 
“Een tool voor alles, gemak en synthese van 
logic designs 
* Hardware onafhankelijk 
* Flexibiliteit indevice keuze, vermindert af- 
hankelijkheid van specifieke produkten 
* Hogere programmeertaal, goede 
* Tijdsbesparing door verbeterde 
leesbaarheid communicatie in een projectteam 
* VHDL is de toekomst 
* Efficiëntie, improved time to market 
Michel Smit 
Field Application Engineer bij SEI 
Sonetech. 
Tel: 040-2635635 


Neem nu een proefabonnement op RB Elektronica, het vakblad op het gebied van de 
elektronica, elektrotechniek en aanverwante onderwerpen. 

ledere maand weer volledig op de hoogte van de allerlaatste noviteiten, nieuwtjes en 

andere wetenswaardigheden. Applicaties in en rond bedrijven komen aan bod, uitleg 


en niet te vergeten de nieuwste ontwikkelingen op het gebied van computertechniek. 
Ook boekennieuws en de agenda vormen een vast item in RB Elektronica. 
Een proefabonnement voor zes maanden (zes nummers!) voor slechts f27,50... 
Nu bellen: (+)0294-450460 of faxen: (+)0294-412782. 
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THEMA: Electronic Design Automation 


Hardware ontwerpen met software 
methodieken 


Inleiding 


Door de sterk toenemende technische mogelijkheden wor- 
den elektronische schakelingen steeds, en steeds sneller, 
complexer. De geschiedenis van het ontwerpen van deze 
schakelingen is echter nog maar kort. Slechts twintig jaar 
geleden werden ASIC’s, die nu als zeer eenvoudig gekarak- 
teriseerd zouden worden, ontworpen op lay-out niveau door 
rechtstreeks de metaal- en andere lagen die aangebracht 
moesten worden, te tekenen. Dit werk was zeer tijdrovend 
en foutgevoelig vanwege de toenmalige beperkte techni- 


sche middelen. 


_ Om de groeiende complexiteit te kunnen bijhou- 
den qua ontwerp productiviteit kwam daarna het 
schema-tekenen in zwang, wat nog steeds veel- 
vuldig wordt toegepast. Deze vooruitgang hield 
in dat men op een hoger abstractie niveau ont- 
wierp: in plaats van de werkelijke patronen op 
silicium, werden nu poorten (gates) getekend 
die vertaald moesten worden naar de patronen 
op silicium. Het lay-out abstractie niveau had 
plaats gemaakt voor het gate-level abstractie 
niveau. 


Thans zijn Hardware Description Languages 
(HDL’s) in vrij korte tijd populair geworden voor 
het ontwerpen van ASIC’s en FPGA's. Daarmee 
wordt het abstractie niveau van ontwerpen op- 
nieuw opgetild naar Register Transfer Level 
(RTL) of zelfs algoritmisch niveau, afhankelijk 
van het niveau waarop de HDL code geschre- 
ven wordt. Een zeer ingrijpende verandering is 
daardoor te zien in de ontwerpmethodieken: 
software ontwerpmethodieken doen hun intrede 
bij het ontwerpen van hardware. 


In dit artikel worden de parallellen belichten tus- 
sen hardware ontwerp met HDL’s en software 
ontwerp en komt tevens een typische HDL ge- 
baseerde hardware ontwerp-flow belichten. 


4.2 Overeenkomsten en 
verschillen 


Bij het beschrijven van overeenkomsten en ver- 
schillen worden de volgende items belichten: 


Overeenkomsten: 
Abstractie niveau 
Taal gebaseerd 
Hergebruik van code 
Code profiling 
Prototyping 
CASE tools 


Verschillen: 
Simulatie 
Timing 


4.2.1 Abstractie niveau 


De overgang van schema-tekenen naar het ge- 
bruik van HDL’s is qua methodiek een overgang 
in abstractie niveau en niet zozeer één van te- 
kenen naar taal. Immers, bij gebruik van 
schema-tekenen wordt een netlist gemaakt, die 
in een taal uitgedrukt wordt. Meestal is dat EDIF 
(Electronic Design Interchange Format). Aan- 
gezien deze netlist echter een beschrijving is 
van componenten en hun onderlinge verbindin- 
gen, leunt deze ontwerp-methode zwaar op gra- 
fische invoer. De taal (de EDIF beschrijving) 
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wordt alleen gebruikt als tussenformaat naar 
andere producten. 


Bij het gebruik van HDL’s wordt het ontwerp echt 
beschreven in taal, waarbij de taal niet dient als- 
uitwisselingsformaat, maar als uitdrukkingsmid- 
del zelf. Daarmee verschuift de aandacht naar 
de specificatie van het ontwerp in een HDL. Het 
doel is nu te beschrijven wat een ontwerp func- 
tioneel (het gedrag) moet doen, in plaats van te 
beschrijven hoe een ontwerp ís opgebouwd uit 
componenten. 


Bij de overgang van schema-teken technieken 
naar een HDL based ontwerpmethodologie is 
dit aspect voor de ontwerper het belangrijkste. 
Het ontwerp wordt gemanipuleerd door middel 
van de taalspecificatie, niet meer door het teken- 
programma. 


4.2.2 Taal 


Behalve het specificatie aspect is de overeen- 
komst natuurlijk overduidelijk het werken met 
tekst. Een goede structurering en opzet van het 
programma met het toepassen van een goede 
coderingsstijl biedt de hardware ontwerper 
leesbaarheid en overzichtelijkheid, daarentegen 
is er ook de mogelijkheid slecht leesbare code 
te schrijven, zoals dat met software ook kan. 


Standaardisatie en daarmee overdraagbaarheid 
speelt ook een rol. Een ontwerp gespecificeerd 
in een HDL conformeert zich aan die program- 
meertaal, niet aan conventies van één bepaald 
product van één leverancier, zoals dat met 
schema-tekenen het geval is. 

Tenslotte kan taal met een tekst editor worden 
ingevoerd en is daarom niet veeleisend in het 
gebruik. Schema-teken pakketten hebben een 
licentie in gebruik gedurende de tijd dat het 
schema getekend wordt, bij een op taal geba- 
seerde aanpak is dat niet het geval. Bijkomend 
voordeel is platform onafhankelijkheid, tekst 
editors draaien zowel op PC als op werkstation. 


4.2.3 Hergebruik van code 

Code hergebruik is een zeer sterke overeen- 
komst met software ontwikkeling. Niemand zal 
voor MS-Windows programma’s zelf nog de gra- 
fische functies programmeren. Deze komen 
namelijk uit standaard beschikbare bibliotheken. 
In HDL's is ook de mogelijkheid opgenomen om 
libraries te bouwen. Run time programmeerbare 
parameters bieden flexibiliteit voor hergebruik. 
Dit is een belangrijk voordeel ten opzichte van 
schema-tekenen waar de vereiste parametrise- 
ring niet kan worden uitgevoerd. Ook standaard 
routines als lezen/schrijven van/naar files kun- 


nen worden opgenomen in bibliotheken. 


Bovengenoemde, in onze ogen triviale, moge- 
lijken zijn echter voor hardware ontwerpers pas 
toegankelijk geworden met de komst van HDL’s. 
Daarvoor was er uiteraard wel hergebruik van 
ontwerpen, maar gebeurde dat meestal door 
stukken van een ontwerp te kopiëren en aan te 
passen aan de nieuwe eisen. Door de HDL’s zien 
we standaard bibliotheken ontstaan die een 
brede functionaliteit bieden. 


4.2.4 Code profiling 


“Profiling” is het bepalen welke stukken code hoe 
vaak worden uitgevoerd. Voor software ontwik- 
keling is dit al jaren een belangrijk middel voor 
snelheid optimalisatie. Profiling geeft inzicht in 
de vraag of alle delen van het ontwerp wel ge- 
bruikt worden. Zo niet, dan zijn er twee moge- 
lijkheden: delen worden niet getest of zijn niet 
nodig, waardoor later redundante hardware ge- 
bouwd wordt. In het traditionele schema-teke- 
nen heeft de ontwerper geen inzicht of al zijn 
componenten wel nodig zijn. 


4.2.5 Prototyping 


Doordat HDL’s simuleerbaar zijn, kan een ont- 
werp al worden getest op functie voordat er ook 
maar iets geïmplementeerd wordt. Er hoeft zelfs 
helemaal geen keuze gemaakt te worden voor 
een realisatie. Een HDL ontwerp kan later zo- 
wel in standaard componenten, als in FPGA’s 
of ASIC’s worden geïmplementeerd. In de soft- 
ware-wereld is dit te vergelijken met GUI 
(General User Interface) builders. Ook hier kan 
een gebruikers interface worden opgebouwd en 
getest zonder dat daar een echte applicatie voor 
nodig is. Daardoor ontstaan er twee voordelen: 
met behulp van simulatie kan getest worden 
ofideeën/functies wel werken én de toekomstige 
gebruiker krijgt zicht op wat de ontwerper nu 
eigenlijk maakt. 


4.2.6 CASE tools 


Voor software ontwerp zijn CASE (Computer 
Aided Software Engineering) tools al jaren be- 
kend. Het hardware ontwerp equivalent hiervan 
wordt nu ook steeds meer gebruikt door ontwer- 
pers. We komen hierop bij het beschrijven van 
de ontwerpflow nog terug. 


4.3 Verschillen 


Er zijn ook een aantal verschillen te noemen. 
We onderscheiden de volgende twee: 
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4.3.1 Simulatie 


Simulatie is het aanbieden van testvectoren aan 
het ontwerp en het observeren van de resulta- 
ten. In de software ontwikkeling wordt de func- 
tionaliteit meestal getest door het ontworpen 
programma te gebruiken. Deze werkwijze is 
mogelijk doordat de ontwikkelstappen snel zijn 
uit te voeren (vooral als deze op één en het- 
zelfde computer platform worden uitgevoerd) in 
de volgorde: programma code; compileren; uit- 
voeren. 


Meestal zijn deze fasen in minuten uit te voe- 
ren. Voor hardware ontwikkeling kan compilatie 
uren duren. Het uitvoeren is afhankelijk van het 
fabriceren van de hardware wat bij een ASIC 
maanden kan vergen en zeer kostbaar kan zijn. 
Simulatie bevordert dat deze tijd-consumerende 
stappen zo min mogelijk worden uitgevoerd. Voor 
een ASIC is het doel “first time right”! 


Een ander belangrijk verschil is dat HDL’s zijn 
ontworpen voor simulatiedoeleinden. Dit heeft 
nieuwe mogelijkheden met zich meegebracht, 
die voorheen in hardware simulatie op poort- 
niveau niet mogelijk waren. Ten eerste kunnen 
test vectoren ook in de HDL’s worden beschre- 
ven waardoor de testvectoren net als het ont- 
werp zelf portable worden. Een tweede moge- 
lijkheid is dat HDL simulatoren interactief kun- 
nen reageren op het ontwerp. 


4.3.2 Timing 


Hardware ontwerpen zijn van nature timing-spe- 
cifiek. Dit brengt met zich mee dat timing onder- 
deel is van de specificatie. Tijd-informatie is dan 
ook onderdeel van HDL’s . Dit biedt de mogelijk- 
heid om deze timing in simulaties op te nemen. 
Simulatie is dan niet meer louter functioneel, 
zoals bij het testen in software, maar gaat een 
stap verder. 


4.4 Ontwerpflow 
4.4.1 Specificatie 


Bij het gebruik van een HDL komt specificatie 
van een elektronisch circuit neer op het schrij- 
ven of genereren (of een combinatie hiervan) 
van een HDL beschrijving. Net zoals in software 
komt zowel het rechtstreeks schrijven als gene- 
reren van de HDL specificatie voor, afhankelijk 
van de complexiteit van het geheel. In de soft- 
ware-wereld hebben CASE tools opgang ge- 
maakt om de groeiende complexiteit van de 
code te beheersen. Het equivalent in de hard- 
ware wereld is eveneens aanwezig en wordt 
Electronic System Design Automation (ESDA) 
genoemd. Een andere benaming hiervoor is ook 
wel: front-end HDL tools. 


Een ESDA tool specificeert een ontwerp. Er 
wordt HDL code gegenereerd uit een grafische 
beschrijving. De gegenereerde code is dan 
syntactisch-correct. De meeste ESDA tools la- 
ten toe dat rechtstreeks HDL code ingevoerd 
wordt op plaatsen waar bepaalde constructies 
het beste in taal kunnen worden weergegeven, 
terwijl graphics wordt toegepast waar die vorm 
duidelijk voordelen biedt. Het grafischedeel van 
het ESDA tool bevat de volgende functionaliteit: 
hiërarchische decompositie, formele specifica- 
tie, type en andere checking, design manage- 
ment en parameters. 


4.4.2 Syntax-directed editors 


Evenals in de software-wereld kent een HDL 
ontwerpomgeving syntax-directed editors. Deze 
tekst editors vullen automatisch veelgebruikte 
syntax patronen aan, geven direkte toegang tot 
de syntax constructies en genereren skeletons 
waarin de gebruiker zijn/haar HDL beschrijvin- 
gen verder kan uitwerken. De HDL code wordt 
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colour-coded weergegeven met regelnummers 
ervoor wat de leesbaarheid vergemakkelijkt, 
evenals het opzoeken van regels code waar een 
bug in wordt gemeld. 


4.4.3 Libraries 


Er bestaan tal van bibliotheken die qua gebruik 
te verdelen zijn in een aantal categorieën: 


Libraries met beschrijvingen van bijvoorbeeld 
timing modellen, file i/o routines en geheugen- 
modellen. Hier kan een parallel getrokken wor- 
den met software libraries die meegelinkt kun- 
nen worden. De gebruiker hoeft hierdoor niet 
alles zelf te definiëren, maar kan een groot aan- 
tal basisroutines uit een library gebruiken. 


Simulatielibraries. Deze libraries bestaan uit een 
groot aantal standaardcomponenten waarvan 
de beschrijving meegesimuleerd kan worden 
met de beschrijving die men zelf gemaakt heeft. 


4.4.4 Simulatie / Source level 
debug 


Een belangrijk onderdeel van het schrijven van 
software is het debuggen van de code. Daartoe 
worden voor alle populaire programmeertalen 
source code debug omgevingen aangeboden. 
Het gebruikersgemak en de features van deze 
omgevingen bepalen in grote mate de snelheid 
van debuggen van de code. Dit alles geldt on- 
verkort ook voor de debug omgevingen van 
HDL. 


Een eerste vereiste is snelheid van werken. De 
“loop” die gevormd wordt door simuleren, een 
fout opsporen in de waveforms, deze fout terug- 
vinden in de broncode door debugging, de bron- 
code aanpassen en opnieuw compileren en si- 
muleren, moet snel te doorlopen zijn. 


Hoewel veel simulatieproducten deze 
funktionaliteit nog gefragmenteerd aanbieden in 
afzonderlijke producten zoals een simulator, een 
waveform viewer en een source debugger, zijn 
er nu ook producten die al deze mogelijkheden 
in één geïntegreerde omgeving aanbieden. 


Verder moeten HDL simulatoren in staat zijn om 
de volledige taalbeschrijving te kunnen simule- 
ren, wil de gebruiker een efficiënt gebruik van 
alle taalconstructies kunnen maken. 


Pure simulatiesnelheid is ook belangrijk. Om- 
dat de taaldefinitie zich uitstrekt over verschil- 
lende abstractie niveaus, dient de simulator zijn 
snelheid ook op al deze niveaus te behouden, 
wil het product efficiënt inzetbaar zijn in verschil- 
lende typen toepassingen. Over het algemeen 
geldt dat naarmate het abstractie niveau van de 
HDL beschrijving afneemt, de simulatiesnelheid 
eveneens afneemt. 


4.4.5 Profilers 


De software-wereld kent een schat aan utilities 
die de programmeur helpen om styling fouten 
te vinden, code te optimaliseren op runtime snel- 
heid etc. etc. Ook de HDL wereld kent tegen- 
woordig deze profiler producten die de code ana- 
lyseren en optimaliseren. Tevens komen er for- 
mele verificatie producten op de markt om au- 
tomatisch, via wiskundige formules, te bewijzen 
dat HDL beschrijvingen op verschillende ab- 
stractie niveaus functioneel gelijk zijn. 


4.4.6 Compilers 


Veel aandacht wordt in hardware automatise- 
ring besteed aan het equivalent van software 
compilers, synthese producten genoemd.Deze 
zetten de HDL code om naar de netlist, de 
assembleer taal van de hardware. Immers, de 
efficiëntie van deze compilers bepaalt de grootte 


van de uiteindelijke realisatie en daarmee een 
belangrijk deel van de kostprijs van de oplos- 
sing. Daar komt bij dat de toepassingen divers 
zijn, met name door de snelle opkomst van 
FPGA's. In tegenstelling tot ASIC architecturen, 
die onderling redelijk op elkaar lijken, hebben 
FPGA's en CPLD’s onderling compleet verschil- 
lende architecturen. Deze vragen dan ook uit- 
eenlopende algoritmen om een efficiënte map- 
ping naar een netlist te maken. De nieuwste 
generatie synthese tools is in staat om een zo- 
danig goede mapping uit te voeren dat hand- 
kwaliteit wordt benaderd. 


De assembler buit de mogelijkheden van de 
onderliggende hardware uit. Zo biedt een goed 
syntheseproduct ook de mogelijkheid de 
architecture van het hardware device, waarop 
mapping plaatsvindt, uit te buiten om een zo 
hoog mogelijke dichtheid te bereiken. Eveneens 
van cruciaal belang is de mogelijkheid om niet 
alleen de controlelogica goed af te handelen, 
maar ook het datapad via het gebruik van 
modulegeneratoren die een rechtstreekse af- 
beelding maken van het datapad op het device. 


4.4.7 Test 


Veel software programma’s kennen hun eigen 
testmodules die over het algemeen in dezelfde 
programmeertaal geschreven zijn als de soft- 
ware zelf. VHDL en Verilog kennen deze moge- 
lijkheid ook. Deze zogenaamde testbenches zijn 
eveneens in die HDL talen geschreven en kun- 
nen in de simulator worden gebruikt voor de 
definitie van stimuli en verwachte resultaten. Alle 
constructies van de taal staan hier ter beschik- 
king van de ontwerper om een goede testset te 
bouwen. Immers, voor complexe ontwerpen 
beschreven in een HDL geldt hetzelfde als voor 
een complex software ontwerp; er treden onver- 
mijdelijk bugs op, waardoor uitputtend testen een 
vereiste is. 


Het schrijven van voldoende testbenches wordt 
bij hardware ontwerp vaak schromelijk verwaar- 
loosd. Het blijkt echter dat voor complexe ont- 
werpen meer dan 50% van de ontwerptijd gaat 
zitten in de testbenches. Daarom loont het om 
ook op dit vlak automatisering toe te passen. 
De nieuwste trends wijzen in die richting: er ko- 
men tools op de markt waarmee testbench ont- 
wikkeling sneller kan plaatsvinden in een soort 
spreadsheet-achtige omgeving. 


4.5 Conclusie 


Het gebruik van HDL technieken biedt grote 
voordelen. Deze komen voort uit het ontwerpen 
op een hoger abstractie niveau en de inherente 
voordelen die gebruik van een programmeer- 
taal bieden. De bijbehorende ontwerpflow wordt 
tegenwoordig ondersteund door een heel scala 
aan hulpmiddelen om snel te kunnen specifice- 
ren, snel en goed te kunnen debuggen en effi- 
ciënte en goed geteste code te schrijven. De 
compilers zijn van een zodanige kwaliteit dat 
handkwaliteit dicht benaderd wordt. 
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Hardware - Software Co-Design 


Introduction 


The ever increasing cost and complexity of electronic 
systems, combined with time to market pressures, are 
forcing design teams to aim for system verification 
(incorporating both the hardware and software system 
components) significantly earlier in the design cycle than 


has traditionally been targeted. 


Using conventional simulation techniques, it has 
proved extremely difficult to execute software 
programs on a simulated hardware description 
without increasing program run-times 
unacceptably. Maintaining compatibility with 
existing software design and debug tools poses 
additional problems. 


Typically, the hardware and software 
components of a system design are brought 
together for the first time when the prototype 
hardware system has been fabricated. As long 
as the inevitable bugs can be fixed in software, 
the system integration is relatively well 
controlled. However, if a hardware bug is 
discovered, a board or ASIC iteration can be 
required to correct the problems. This option can 
have such serious implications for project costs 
and schedules that, instead of having to iterate 
the design, compromises in performance or 
functionality are often accepted. 


The pressing need for solutions to allow hard- 
ware and software to be verified before the hard- 
ware is built - Virtual Systems Integration - is 
being exacerbated by several significant industry 
trends. As systems become more complex, soft- 
ware has become the dominant component in 
the system ( there is a ratio of 4 software engi- 
neers for each hardware engineer, and this ra- 
tio is increasing ). The interaction between the 
software and the hardware is critical to the cor- 
rect system function. 


Hardware designers are turning to more 
powerful processor families to handle the 
increased software requirements. 32-bit proces- 
sors are increasingly popular for a wide range 
of applications. However, these processors 
require more complex tools for the associated 
software design. Most code development is 
done using a high level language. It is not 
practical to write and debug system software at 
assembly level. As 70% of ASICs design today 
are designed to work with processors, ASIC 
manufacturers now provide complex micro- 
processors as cores on ASICs.. It is possible to 
build a processor, RAM, ROM and custom hard- 
ware onto one ASIC. This poses an interesting 
question :- Is a software bug on an ASIC ROM 
a software or a hardware bug? 


The ability to verify and debug the software and 
hardware together before the hardware is built 
would not only be a significant step forward in 
detecting and correcting design errors, but would 
help in realising the first levels of system 
integration. Figure 1 compares conventional sys- 
tem design flow with Virtual Systems Integration. 
Almost all the time savings achievable are due 
to the fact the debug, verification and system 
integration can begin before the hardware pro- 
totype is built. This article reviews existing sys- 
tem simulation strategies and their limitations. 


AG 


Automation have developed a unique technology 
that brings together existing hardware and soft- 
ware design toolsets into a unified debug and 
verification environment capable of executing 
software programs a thousand times faster than 
conventional simulations. 


Often, the first attempt at system simulation is 
to cross-compile the software program down to 
object code. The object code can be loaded into 
a simulator memory model, together with a full 
functional model of the system processor and 
the associated peripherals and ASICs. The ob- 
ject code within the memory can be executed 
on the processor model. 


However, there are some significant drawbacks 
to this approach. Program execution speed is 
unlikely to be fast :- a typical rate of execution is 
2 to 3 microprocessor instructions per second. 
Model availability can also be a problem - most 
processor manufacturers are not keen to release 
full-functional models of advanced processor in 
case the design is reverse engineered into a 
competitive product. 

One solution to these problems is to use a hard- 
ware modeller. This allows a real chip to be 
included in the simulation which solves the 


modelling problem. The speed of simulation also 
increases but typically only by a factor of two. 
However, if the chips are not static, or if multiple 
instances of the processor are used, the hard- 
ware modeller is required to store and rerun on 
all the previous simulation vectors for each 
simulation cycle. As the simulation progresses, 
the instruction rate decreases; and the vector 
memory fills up. 


Consequently, most designers set their sights a 
little lower and use bus functional models of pro- 
cessors. These models are an excellent way of 
verifying the interaction of each type of bus cycle 
in the system. Scripts can be used to put 
together sequences of bus cycles to emulate 
specific groups of instructions, but true program 
execution is not possible. All these techniques 
suffers from one more serious drawback. Even 
if these methods were powerful enough to run 
significant amounts of code allowing bugs to be 
detected, because all the code is at object level 
it would be extremely difficult and time consu- 
ming for a software engineer to diagnose the 
cause of a problem. There is no access to any 
of the standard diagnosis tools such as debug- 
gers and code profilers at the object code level. 
For complex microprocessors, this makes it 
almost impossible to debug and diagnose the 
detected problems. 


Fig. 1 Virtual Systems Integration Enables Early Debug and Design Verification. 
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5.3 System Design 
Methodology Trends 


There are a number of trends in both software 
and hardware design that can be extended to 
construct a Virtual System Integration environ- 
ment. System software that utilises hardware 
functionality tends to be well structured. A 
general rule is that all the low-level functions that 
interact directly with the hardware are confined 
to ‘driver’ functions. This means that when the 
hardware changes or a bug is found in the 
interaction between the software and hardware, 
the code that has to be rewritten is localised in 
one place only. 


Of course, much of the software is written while 
the hardware is being designed. Until the hard- 
ware is complete there is no target system where 
the software can be executed. The way around 
this problem is that, writing in a high level 
language, the code can be cross-compiled onto 
another system such as a workstation. This 
works well until the hardware drivers are 
executed - there is no custom hardware with 
which the software prototype can interact. A 
common technique is to substitute the hardware 
drivers with ‘fake’ driver functions. The ‘fake’ 
drivers attempt to provide some sort of response 
back to the main body of the software program 


that emulates the actions of the projected hard- 
ware. 


In some cases these fake drivers are minimal 
functions that provide the most limited respon- 
ses - but enough to allow testing of the main 
body of the software. In other cases the ‘fake’ 
drivers are extremely complicated functions that 
emulated many aspects of the projected hard- 
ware. In fact, in such cases, there is often a sig- 
nificant amount of work done to verify that the 
drivers and the hardware description match. This 
can be an extremely difficult task because the 
driver functionality is mainly in a ‘sequence’ 
domain while the hardware description executes 
in atime domain. These techniques allow much 
of the software to be tested independently of 
the hardware. What is not verifed is the inter- 
action between software and hardware. 


For hardware design, the overwhelming trend 
over the last ten years has been a shift away 
from gate-level schematic capture towards 
language based design entry. This has been 
underlined by the acceptance of standard Hard- 
ware Design Languages (HDLs) such as VHDL 
and Verilog. Within language based design, 
designers are beginning to realise the benefits 
of behavioural modelling before the more familiar 
Register Transfer Level (RTL) descriptions are 


created. One of the main reasons for higher- 
level design abstraction is that more testing and 
verification can be done earlier in the design 
cycle before the gate-level design is started. This 
allows design errors introduced at an early stage 
in the design to be detected and fixed as early 
as possible. 


Putting these two trends together shows that 
early in the design project there exists proto- 
type software that can be run independently of 
the ultimate target hardware; and a functional 
HDL description of the projected hardware. 


Eagle Design Automation has put these two 
components of the system together using unique 
technology to create a virtual environment in 
which the HDL description and the prototype 
software can be executed together. 
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System specification, analysis and 
implementation 


Language Independence, the Future of the EDA Industry 


For several years now, the EDA industry has been locked in 
a battle over which hardware description language (HDL) to 
support as a standard. After much debate the marketplace 
has voted and a clear winner selected - both. 


This state of affairs may catch even some EDA 
veterans off guard, but the decision is a logical 
one. Both Verilog and VHDL, the primary 
contenders, have their numerous proponents 
across the EDA industry and among both 
designers and vendors of ASICs and ICs. Men- 
tor Graphics has long supported standards such 
as VHDL. This commitment to VHDL is due to 
the natural strengths of VHDL, and because its 
IEEE-1076 specification prevents the difficulty 
of supporting an ambiguous and changing 
specification. 


With the adoption of the IEEE-1364 standard 
for Verilog, Mentor Graphics has begun the 
process of supporting functionality that will allow 
it to provide Verilog point tools and design flows. 
In addition to supporting VHDL and Verilog 
separately, Mentor Graphics has developed tools 
that can support both VHDL & Verilog 
simultaneously. 

This need for mixed language designs as been 
identified by several key customers and is a 
requirement for the emerging Systems on Silicon 
Initiative(tm). Support for both languages, or 
language independence, means that electrical 
engineers can bring together any combination 
of Verilog and VHDL into a single design. In 
essence, language independence means 
freedom. Designers can now design, simulate, 
and synthesize a circuit using either Verilog or 
VHDL or mixed VHDL and Verilog. By allowing 
this mixed HDL support, Mentor Graphics adds 
language independence to the implementation 
independence already enjoyed by HDL users. 
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6.2 Removing Barriers 


The foremost benefit of language independence 
is that it opens doors to design reuse by 
safeguarding the investment a company makes 
in intellectual property. Such property can take 
anumber of forms. It can be the processor core 
at the heart of a new IC for the hand held market. 
Or it can be the stimulus for verification of a 
VHDL circuit. It can even be the methodology 
for creating Verilog or VHDL cell libraries - a 
methodology that’s been created by a design 
team over a period of many months. 


Chances are excellent that at some time a 
company will need to use that intellectual 
property on a new design. The growing 
complexity of electronic circuits resembles, in 
some ways, a snowball rolling downhill. To pack 
ever-more functionality onto a chip, within a 
shrinking time-to-market, design teams are fin- 
ding new ways to re-use previously developed 
intellectual property. ICs and ASICs that used 
to be standalone are now being combined into 
larger systems on silicon (SOS). The design 
becomes larger and time to market shrinks (the 
snowball get larger and speeds up) until it 
reaches a barrier. For most customers, that 
barrier is encountered early in the process and 
that barrier is model availability (the VHDL 
customer who needs a processor model only 
available in Verilog, for example). 


Language independence simply removes the 
traditional barriers to design reuse and model 


availability. A piece of code written in Verilog 
can be applied to VHDL designs and vice versa. 
Companies are assured that existing intellectual 
property will remain viable for the foreseeable 
future. 


One area or particular interest to designers is 
the re-use of stimuli for verification. It has been 
estimated that the creation of stimuli for a given 
design module can consume roughly 25% to 
75% of the time spent on the design task. With 
language independence, stimuli developed for 
a Verilog design can be used on a part 
developed, synthesized, or re-implemented in 
VHDL, or vice versa. 


6.3 Increasing Choice 


Along with the benefits of design re-use, design 
teams are free to use VHDL, Verilog, or a 
combination of the two, depending on which is 
best suited for a particular design. This choice 
is important to the EDA industry because both 
languages offer advantages. For instance, VHDL 
includes constructs that make it better suited for 
designs at the behavioral level (such as VHDL 
types, package and library definitions, third party 
tools, and specialized packages). 

Verilog enjoys the widest support among ASIC 
vendors today and is the predominant 
verification methodologyfor many designers, 
although with the IEEE-1076.4 VITAL 
specification VHDL designers will have 
significantly increased ASIC library support in 
the future. 
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One final advantage of language independence 
is that designers are essentially free to choose 
among ASIC vendors and libraries. The laws of 
marketplace economics say that an increase in 
vendor selection should help lower costs and 
improve productivity. 


Of course, not everybody will be happy with the 
new state of affairs. Less efficient ASIC ven- 
dors and library suppliers may find their positions 
further eroded, while their more successful 
brethren pull further afield. Tool vendors who do 
not provide the flexibility of mixing VHDL & 
Verilog will likely see their revenues and 
customer base shrink as well. But for the industry 
as a whole, language independence is an 
opportunity to increase the re-use of intellectual 
property while improving productivity in the 
development of new designs. At Mentor 
Graphics, language independence will be a key 
feature in the joining of smaller blocks and cores 
into Systems on Silicon, a trend that will help 
propel the EDA industry into the twenty first 
century. In the simulation field, Mentor Graphics’ 
new product QuickHDL (tm) provides the ability 
to seamlessly mix VHDL and Verilog languages 
today. 


6.4 Simulation Technology 


QuickHDL(tm) is the next generation of Mentor 
Graphics’ existing QuickVHDL(tm) product that 
has allowed Mentor Graphics to meet the needs 
of VHDL designers. Like Quick VHDL, QuickHDL 
uses Direct-Compiled Code Technology to 
reduce HDL descriptions into a compiled data- 
base of binary generic RISC instructions. These 
instructions are then easily mapped to the target 
workstation instruction set and executed by the 
new Single Kernel Simulator (SKS). This 
methodology allows for fast compilation, fast 
simulation, seamless language mixing, and plat- 
form independence for compiled designs. 


Most simulators allow the use of different models 
through the technique of co-simulation. This 
allows two different simulators to pass results 
between them to support mixed simulation. 
Some products today which are not positioned 
as co-simulation products, but allow model 
importing are actually co-simulation products 
since two different simulation kernels are used. 
The simulation kernel is the part that evaluates 


results based on the design, stimulus, and pen- 
ding events. QuickHDL has only one kernel that 
is capable of executing the instructions compiled 
from VHDL or Verilog without the performance 
and memory overhead of a multiple kernel ap- 
proach. The SKS technology also supports the 
use of foreign models such as LMG SmartModel 
libraries, LMG Hardware Modelers, and models 
written in C. 


However, no approach is correct for all situations. 
While a single HDL simulator is best for mixing 
the VHDL and Verilog languages, supporting 
other existing model types such as Mentor 
Graphics’ QuickSim Il(r) models or 
Continuum(tm) analog models would be 
inefficient within a single simulator. For this 
reason, QuickHDL supports an optional co- 
simulation interface to allow the mixing of VHDL, 
Verilog, schematics, or analog models. 


Once a simulation tool provides performance 
and support for the necessary models, a 
designer’s needs turn to validating the design. 
Due to the increasing complexity of today’s de- 
signs, the need for sophisticated and easy to 
use debugging capabilities can have significant 
impact on the overall design cycle. QuickHDL 
supports the ability to view source code, view 
current values (on signals, variables, registers, 
and wires), view results in a graphical waveform 
or tabular list format, view the design structure, 
view HDL connectivity in a dataflow format, and 
see pending events in processes. Since these 
capabilities are being provided in a Single Kernel 
Simulator, all these services are available for 
either VHDL, Verilog, or mixed HDL designs wit- 
hout restriction. 


Once the designer has done some initial 
validation, the need often arises to use a 
scripting language for building routines that 
check for complex conditions or for use in 
automated regression tests. QuickHDL uses the 
industry standard TCL (Tool Command 
Language) scripting language format for this 
purpose like it's predecessor QuickVHDL, which 
was the first commercial simulator to support 
TCL. 


6.5 Links to Design Flows 


Of course no matter how efficient a simulator is, 


it just part of the total design process. In order 
to make the design process more productive, a 
simulator must have excellent links to upstream 
and downstream tools. QuickHDL allows for data 
input from multiple sources such as text editors 
(HDL text format), Mentor Graphics’ Design 
Architect(tm) (HDL text format, schematics), and 
System Architect(tm) (data flow diagrams, state 
tables). When non-text input mechanisms are 
used, QuickHDL uses links to the entry tools to 
allow debugging with graphical representations. 


Since many HDL designs will be synthesized, 
QuickHDL also has the ability to perform 
synthesis checks for Mentor Graphics AutoLogic 
Il(tm) synthesis tool at compile time. This 
prevents the designer from spending significant 
time simulating a design only to find out that it is 
not synthesizable and requiring design and 
validation work to be repeated. 


After synthesis, verification and timing simulation 
is the final simulation step. QuickHDL supports 
the industry standard SDF file format for 
backannotating delays to either VITAL (VHDL) 
or Verilog models allowing QuickHDL to fit 
existing flows and use delay information from 
ASIC vendor tools, user written tools, or other 
EDA vendor tools. 


6.5 Summary 


In order for designers to meet the challenges of 
tomorrow’s designs, they will need to have 
freedom in model and library choices, efficient 
ways to validate and verify those designs, and 
open, flexible design processes. By taking the 
implementation independence enjoyed by HDL 
simulators and extending that to include HDL 
independence, QuickHDL provides a 
cornerstone technology that will enable 
designers to solve the problems facing Systems 
on Silicon. 
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Optimaliseren van het 
ontwerp-proces 


Inleiding 


Dit artikel probeert aan te tonen dat er een trend valt waar te 
nemen in het optimaliseren van het totale ontwerpproces en 
dat de fabrikanten van elektronica, die willen overleven, 
nieuwe ideeén zullen moeten toepassen op het gebied van 
elektronica ontwikkeling teneinde in de toekomst nog een 


rol van betekenis te spelen. 


Fabrikanten zijn of worden in de komende jaren 
geconfronteerd met enorme problemen aan- 
gaande het plannen en ontwikkelen van nieuwe 
produkten. Deze problemen worden groter wan- 
neer tegelijkertijd een steeds groter wordend 
aantal bestaande produkten in de markt gehand- 
haafd dient te worden. “Time-to-market’ en ‘First- 
time-right’ design zullen meer dan ooit van vi- 
taal belang zijn voor het succesvol introduce- 
ren van nieuwe produkten. 
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1.2 Traditionele produkt 


levenscyclus 

Produktlevenscycli worden steeds korter. We 
zagen vroeger dat de ontwikkeling van het ene 
produkt alléén de volgende overlapte. Zodra er 
een produkt uit de markt werd genomen, nam 
een ander zijn plaats weer in. Kenmerkend van 
dit model is dat gedurende de introductiefase 
van een nieuw produkt de ontwikkelkosten wor- 


den terugverdiend en dat bovendien in deze fase 
een hogere prijs berekend kan worden. Klanten 
zijn namelijk bereid voor de nieuwe mogelijkhe- 
den extra te betalen. In de daaropvolgende 
exploitatiefase zullen derhalve relatieve hoge 
winsten op een bepaald produkt gemaakt kun- 
nen worden. 


Ontwikkeltijd en time-to-market zijn niet echt van 
belang bij deze traditionele benadering. Een 
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Boompje opzetten? 


Niet meer nodig. Boom staat al. De professionele 
elektronicus heeft voortaan aan één woord genoeg. 
Onder de projectnaam Sequoia bied Accel Technologies 
Inc. de mogelijkheden van TangoPRO en P-CAD, 
verenigd in een nieuw krachtig produkt: ACCEL EDA. 


Dit verrassend veelzijdige programma voor Schema 
invoer, PCB lay-out, Routing en Bibliotheekbeheer 
werkt onder Windows 3.11, Win NT of Windows 95. 
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Titel: Werken met SPSS 
Base 

Uitgeverij: Sybex 

Voor Nederland: 

De Muiderkring B.V. 
Bestelnr. 750.737 

Prijs: fl. 69,- 


Als er één terrein van 
onderzoek is waar de 

* computer al snel onmisbaar 
bleek, dan is het wel 
statistiek. SPSS is een 


programma waarmee u 
statistische analyses 

uitvoert op meetgegevens. 
Werken met SPSS gaat er 


vanuit dat de grondbeginselen en de terminologie van 
de statistiek u bekend zijn. Van computers hoeft u niets 
af te weten. Het tweede hoofdstuk geeft onder andere 
een gedegen opleiding in het programma. 

Hoofdstuk 3 geeft uitleg over de data-editor, de plaats 
waar de gegevens worden opgeslagen. U krijgt een 
antwoord op vragen als: hoe zijn de gegevens gestruc- 
tureerd, hoe beoaalt u het type ervan en hoe voegt u 
nieuwe gegever.s toe of verwijdert/wijzigt u bestaande”? 
Hoofdstuk 4 behandelt het bestandsbeheer en in 
hoofdstuk 5 wordt aandacht geschonken aan het 
‘output'- en 'syntax'-venster. Hoofdstuk 6 laat zien hoe 
u de gegevens in de data-editor bewerkt. Aan de orde 
komen zaken als sorteren, samenvoegen/splitsen van 
een aantal bestanden en het wegen. Hoofdstuk 7 toont 
hoe u data kunt transformeren om bijvoorbeeld niet 
relevante gegevens te filteren. 
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goed produkt is namelijk beschikbaar en de 
ontwikkelkosten kunnen worden betaald uit de 
prijsopslag van een nieuw produkt tijdens de 
introductieperiode. 

Echter bedrijven en individuen die nog steeds 
het enkelvoudige beeld van produktontwikkeling 
gebruiken, werken met een gevaarlijke misvat- 
ting en lopen het risico overgenomen te worden 
door de concurrentie of met een nieuw produkt 
de markt volkomen te missen. 


1.3 Huidige en/of toekom- 


stige produktlevenscyclus 


Als gevolg van het elkaar steeds sneller opvol- 
gen van nieuwe technologiën en invloeden van- 
uit de markt, is de produktontwikkelperiode veel 
korter geworden. Dit heeft tot gevolg dat de 
beschikbare tijd tussen de start van de ontwik- 
keling en het moment van introductie van vitaal 
belang is voor het succes van een nieuw pro- 
dukt en dus voor het succes van de onderne- 
ming. 


Dit heeft enkele zeer belangrijke effecten tot 

gevolg: 

Verschillende versies van een produkt zullen nu 
tegelijkertijd op de markt aanwezig zijn, waar- 
bij de complexiteit en de compactheid van de 
ontwerpen zal toenemen. Daarnaast zal de 
druk op een concurrerende (kost)prijs en de 
kwaliteit blijven bestaan of zelfs toenemen; 

Produktversies zullen sterk verschillende levens- 
verwachtingen hebben; 

Produktontwikkeling zal een continu proces 
worden. 


In plaats van een ontwikkeling te zien als een 
eenmalige investering en af te schrijven tegen 
toekomstige winsten, is tegenwoordig ontwik- 
keling een constante en terugkerende kosten- 
post en daarom zal hiervoor een budget moe- 
ten worden vrijgemaakt. 


1.4 Trends in de 


Electrotechnische Industrie 


Zoals reeds in de vorige paragraaf uiteengezet 
resulteert een kortere produktlevenscyclus in het 
feit dat het produkt in een kortere tijd zijn inves- 
teringen moet hebben terugverdiend waarbij 
doorgaans de kwaliteit, complexiteit en 
compactheid gehandhaafd moet blijven of zelfs 
moet worden verbeterd. Er vindt een verschui- 
ving plaats naar een continue produkt- 
ontwikkeling in plaats van periodieke ontwikke- 
lingen ten tijde van de noodzaak van een nieuw 
produkt. 


Genoemde verschuiving stelt andere eisen zo- 
wel aan de ontwikkelaar als aan het bedrijf. De 
ontwikkelaar zal een gezonde mix moeten vin- 
den in een combinatie van ontwikkelaar, produkt- 
manager en service engineer. Daar tegenover 
staat een noodzakelijke verandering in de ma- 
nier waarop het bedrijf nieuwe ideeën en 
technologiën implementeert. Indien technici een 
bredere rol moeten vervullen en dus algeme- 
ner gericht zullen zijn, kan men niet verwachten 
dat ze alle technieken kunnen beheersen om 
een nieuw produkt te ontwikkelen. Uitstekende 
hulpmiddellen voor de ontwerper zijn hierbij 
natuurlijk de EDA ontwerp tools. 


De vraag werpt zich op voor welke technologie 
implementaties de eigen technici worden ge- 
bruikt en voor welke niche- of speciale 
technologien partners kunnen worden ingescha- 
keld. 


Kenmerkend zijn dan ook de volgende trends in 

de elektrotechnische industrie: 

Design anywhere /make anywhere. Er ontstaan 
ontwerpende bedrijven en producerende be- 
drijven. De keuzemogelijkheid tot uitbesteden 
speelt hierbij een belangrijke rol. 
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Inereasing clock-speed. De vraag naar meer 
functionaliteit in minder tijd dwingt de elek- 
tronica ontwerpers met een steeds hogere 
klokfrequentie te gaan werken. 

Decreasing time-to-market. De produktlevens- 
eyclus wordt korter, verschillende versies van 
hetzelfde produkt zullen tegelijkertijd op de 
markt aanwezig zijn met als gevolg dat het 
moment van marktintroductie van een produkt 
van vitaal belang is geworden. 

Increasing software content. (Embedded) Soft- 
ware zal bij elektronica ontwikkeling een 
steeds groter rol spelen. 


1.5 Systeemontwerper en 


zijn gereedschappen 


Degenen die als eerste worden geconfronteerd 
met de gevolgen van een kortere produktlevens- 
cyclus en de trends in de elektronica industrie, 
zijn de systeemontwerpers. Onder een steeds 
hogere tijdsdruk moet de ontwerper meer de- 
signs produceren en tegelijkertijd onderhouden. 
Daarnaast moet dezelfde ontwerper in staat zijn 
op de hoogte te blijven van de technologische 
ontwikkelingen en deze weten te implementeren 
in de nieuwe designs. 


De vraag die een ieder zich hierbij stelt is: op 
welke manier kan de ontwerper en dus ook het 
bedrijf binnen de beschikbare tijd en beschik- 
bare kennis toch de gewenste ontwerpen op tijd 
en conform specificatie leveren. Het antwoord 
hierop is niet in enkele woorden te geven, maar 
een essentiële rol hierbij is wel dat de totale 
Design Flow en niet de afzonderlijke ontwerp- 
processen (specificatie, functioneel ontwerp, 
detailontwerp, implementatie, verificatie, testen, 
etc.) geoptimaliseerd moeten worden. Het gaat 
hierbij om een totale geïntegreerde oplossing 
die het de ontwerper mogelijk maakt zich bezig 
te houden met zijn taak; ‘het ontwerpen van elek- 
tronica’ en niet met het op elkaar afstemmen 
van de afzonderlijke processen en/of gereed- 
schappen. 


Veruit het grootste deel van het niet juist func- 
tioneren van een bepaald ontwerp ontstaat in 
de specificatie fase. Het controleren van het 
gedrag van het totale systeem in een zo vroeg 
mogelijk stadium, zonder gekozen te hebben 
voor de uiteindelijke technologie (hardware, soft- 
ware, ASIC, FPGA, etc.), maakt kostbare re- 
designs, het uitstellen van de introductie van een 
nieuw produkt en/of extra prototypes overbodig. 


Een voorbeeld waaruit de essentie blijkt van een 
geïntegreerde Design Flow in plaats van geop- 
timaliseerde afzonderlijke ontwerp-processen is 
het volgende: Met grote regelmaat worden de 
noodzakelijke wijzigingen in het lay-out proces 
niet teruggekoppeld naar het functioneel ont- 
werp met als gevolg dat bij een re-design van 
het eerste ontwerp de lay-out designer opnieuw 
de problemen van het eerste design moet op- 
lossen. Deze vorm van ‘over the wall’ ontwer- 
pen is funest voor het time-to-market principe 
en zal derhalve nooit kunnen resulteren in ‘first- 
time-right’ ontwerp. 


Een tweede kenmerkend voorbeeld om de 
sleutelfactor ‘time-to-market’ te reduceren is het 
tegelijkertijd ontwerpen van hard- en software 
en de daarbij behorende simulatie. Het is een 
bekend verhaal: Nieuws over het nieuwe pro- 
dukt lekt uit naar de markt. Klanten vragen naar 
het produkt en de verkopers kunnen niet wach- 
ten met het onder de aandacht brengen van de 
nieuwste ontwikkelingen. Praktisch iedereen in 
het bedrijf kijkt uit naar de introductie van het 
nieuwe produkt. ledereen, behalve de ontwer- 
pers aangezien zij wanhopig proberen de soft- 
ware op tijd klaar te stomen. 


De vraag die hierbij telkens weer opdoemt is, 
waarom wordt er nog steeds gewerkt aan de 








software ontwikkeling? Het simpele antwoord 
luidt dat de software pas wordt getest en 
gedebugged nadat de hardware getest en 
gedebugged is. Het functioneel testen cq simu- 
leren van het gedrag van het totale systeem zou 
de zekerheid hebben gegeven dat het systeem 
conform de specificatie wordt ontworpen. Bo- 
vendien zouden in deze hardware/software co- 
design omgeving beide disciplines tegelijkertijd 
hun werk kunnen verrichten met als gevolg dat 
de totale ontwerptijd aanzienlijk afneemt. 


Samenvattend zijn de meest belangrijke sleutel- 
factoren ten aanzien elektronica ontwerp me- 
thodes dan ook: 


Hoog niveau ontwerp-methoden (High Level 
System Design) 

Hardware/Software co-design 

Integratie van het gehele ontwerp-proces vanaf 
specificatie tot aan realisatie en implementatie. 


1.6 Conclusie 


Belangrijk bij de keuze van een ontwerptool is 
dat het bedrijf niet alleen de capaciteiten van 
de afzonderlijk tool in ogenschouw dient te ne- 
men maar juist moet analyseren hoe de totale 
Design Flow verbeterd kan worden. Uit het voor- 
beeld van Hardware/Software co-design blijkt 
heel duidelijk dat het niet alleen gewenst is, maar 
zelfs noodzakelijk is, dat gedragssimulatie van 
het gehele systeem in zo vroeg mogelijk sta- 
dium moet plaatsvinden. Alleen op die manier 
kan men voorkomen dat kostbare re-designs, 
design iteraties en/of prototypen tot een mini- 
mum beperkt worden. Dit zal tot gevolg hebben 
dat alleen bedrijven die deze methodes toepas- 
sen als eerste met het nieuwe produkt op de 
markt zullen verschijnen en derhalve hun con- 
currentiepositie zeker stellen. 


Verder is het van groot belang dat gebruik ge- 
maakt wordt van gereedschappen die het mo- 
gelijk maken technologie onafhankelijk te ont- 
werpen. Te denken valt hierbij aan het grafisch 
voorstellen van het ontwerp met de mogelijk- 
heid om vanuit die grafische omgeving het sys- 
teem te simuleren en code te laten genereren 
van hogere beschrijvingstalen (VHDL/Verilog). 
Alleen met deze methodieken wordt het moge- 
lijk de steeds complexere en compacter wor- 
dende elektronica ontwerpen te blijven ontwik- 
kelen en te hergebruiken. 


Tot slot maken deze methodieken het in de eer- 
ste plaats mogelijk de technologie onafhanke- 
lijke ontwerpen te hergebruiken in nieuwe de- 
signs. En ten tweede bestaat de mogelijkheid 
het bestaande ontwerp te implementeren in een 
nieuwe technologie zonder de noodzaak van 
een kostbaar re-design. 


Ing. C. Stemerdink 

MGB, authorized distribution Benelux 
Enschede 

Tel. +31 (0)53 4336665 


Uw vakblad: iedere maand 
boordevol informatie, 
wetenswaardigheden, 

nieuws en dat tegen de 
meest aantrekkelijke prijs. 


Proefabonnement f27,50 
… NU DOEN... 
Bel.0294-450460 
of 
Fax 0294-412782 


RB Elektronica, mei 1996 





THEMA: Electronic Design Automation 


Gaining Control Over the Escalating 
Complexity of Design Data 


Abstract 


Over the past decade substantial improvements have been 
realized in the electronic design process through the use of 
computerized tools that automate various tasks in the de- 
sign process. The impact on product performance, quality 
and time-to-market has been dramatic. However, along with 
the use of these tools has come new issues that add 
complexity to the process and, if not addressed, can have 
adverse effects on achieving overall design productivity 
goals. This document describes the issues that arise from 
the productivity of electronic data and the solutions that are 
available to address the problems. 


2.2 Introduction 


The use of EDA tools has resulted in an 
exponential rise in the numbers of interrelated 
computer generated files that often must be 
shared among design team members. Because 
tools like simulators, design synthesizers and 
autorouters make it easier to consider different 
approaches, more design alternatives are 
evaluated resulting in more design configura- 
tions and versions. These versions are main- 
tained in either local or shared file systems, 
usually without any automated means of design 
file management. The growing use of concur- 
rent design practices requires that these design 
files be easily accessed by both the designer 
and other team members. As the complexity of 
locating the correct files and versions of files gets 
out of control, design productivity suffers. 
Another design productivity issue is the 
infrequent reuse of older designs. If it is difficult 
for engineers to search and locate previous de- 
signs, they usually resort to starting over from 
scratch. This practice of “reinventing the wheel”, 
can be avoided by providing easy searches and 
access to older designs for reuse on new 
projects. 


Design Data Management (DDM) and Product 
Data Management (PDM) systems are two dif- 
ferent but complementary solutions to the 
problem. Both solutions use “storage managers” 
or electronic vaults to store and provide access 
to design files. The first (DDM) addresses the 
needs of engineering workgroups where the 
design is rapidly changing. The second (PDM) 
addresses the broader needs of the organization 
as the product is readied for manufacture. At 
this stage, because the various users are located 
throughout the organization, more formal 
configuration management revision control, 
release procedure and engineering change or- 
der management is needed. 


Design Data Management (DDM) provides high 
level searching, browsing and access controls 
that are needed by the designer or workgroup 
members to make it easy to access the correct 
versions of a design without the worry of multi- 
ple designers simultaneously making changes 
to the same design files. This type of control 
system prevents the loss of days or weeks that 
often results from accessing incorrect versions 
or redoing work that has already been done. 


As designs are released to manufacturing, 
electrical design data joins other product data 
that may include the bill of materials, mechanical 
drawings, manufacturing drawings, manufactu- 
ring automation files, manufacturing instructions, 
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product documentation, etc. Design access and 
control issues that arise at this level are common 
concerns across the enterprise rather than 
simply within the electrical design workgroup. 
As design information is promoted to the 
enterprise level, the information changes less 
frequently and a larger number of people need 
input and access than at the workgroup level. 
Product Data Management (PDM) systems are 
used to manage the information that is required 
to build and support the complete product. The 
integration of electrical data into these “storage 
managers” requires a detailed understanding of 
electronic design tool data structures and is 
usually the most difficult aspect of PDM system 
integration. 


2.3 What Is Data 
Management? 


Data Management is the management of all the 
product information flowing through an 
organization that is required in the development 
of new products or in updating of current ver- 
sions of products. This information may be held 
in files or in levels of abstraction in a database. 
Adata management system should make it easy 
to understand and control all of the design data 
such that authorized team members can quickly 
gain access to stored design information to 
either view, edit or reuse the design without con- 
cern that others are changing the same design. 


Today’s enterprise PDM solutions do little to 
address the needs of electronic design 
workgroups. The reasons for this are that 
electronic data, in the design phase, changes 
much more frequently than after the design is 
released and electronic design data is 
fundamentally different than the majority of other 
product data. Some of these differences are as 
follows: 

Electronics data is highly abstract and often has 
no direct relationship to a physical entity that 
a person can see, feel or touch. This makes 
it difficult for a person that is not expert in elec- 
tronic tool data structures and design 
practices to characterize electronic design 
data so that it can be properly and efficiently 
managed by a PDM system. Schematics, 
netlists, simulation results, EEPROM, PROM, 
and PAL data are examples of abstract data 
entities and the rules that must be obeyed to 
incorporate design changes are not at all 
intuitive. 

Every EDA system has its own proprietary set 
of data structures that often are not well 
documented. Experience in dealing with elec- 
tronic design data is necessary to understand 


the data model and is thus a prerequisite in 
integrating electronic design data in a PDM 
system. 

Alarge percentage of the information that makes 
up an electronic design is sourced from com- 
ponent libraries that support the design tools. 
These libraries undergo constant change. 
Managing design files without managing the 
source of the component data can result in 
incomplete or inaccurate product data. Thus 
component libraries need to be managed and 
the version numbers referenced in the design 
data as well. 

Electronic designs contain many levels of 
hierarchy and often a design block is replica- 
ted many times with each instance containing 
different reference designators. In managing 
electronic data, it is important to maintain de- 
finitions of this hierarchy so that rapid access 
at any level is possible without encountering 
time consuming “unpacking” procedures. 

ASIC design is often entered behaviorally. This 
level of abstracfion is twice removed from 
physical design. Dependencies between pre 
and post synthesized representations com- 
pound the logical/ physical data dependencies 
found in PCB design. 


Most solutions that address the DDM issues 
have come from EDA companies. While these 
companies certainly understand electronic data 
issues, most of their efforts in data management 
have been too limited in scope. In one approach, 
dedicated DDM products for electronics data 
have focused exclusively on the data from a sin- 
gle vendor. This is typical of the wall to wall EDA 
supplier that assumes all EDA tools will be 
purchased from a single suplier. Another ap- 
proach involves the EDA vendor attempting to 
sell a proprietary storage management system. 
This approach denies a whole industry outside 
of EDA which focuses on providing the best 
storage management technology. In either case, 
requirements for openness and ease of 
integration with other storage managers has 
fallen short of customer needs. 


2.4 Why is Data Management 
Needed? 


While there has been enormous improvements 
in the productivity of individual design tools, the 
overall sophistication of new products is growing 
faster. Competitive forces dictate that to survive, 
companies must strive to obsolete their own 
products before competitors do it for them. A 
widely quoted study by McKinsey & Co. found 
that with a reasonable set of market assumpti- 
ons, a six month product slippage results in a 
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33% erosion of net profits. 


In industries such as personal computers, prin- 
ters and peripherals, the total product life cycle 
is often less than one year. Businesses 
everywhere are looking for ways to get more with 
less. While CAE, CAD and CAM solutions are 
now standard in most engineering departments, 
procedures for validating, reviewing, circulating 
and approving changes is still largely done on 
paper. The review process itself, often takes 
more time than the implementation. The quantity 
of data produced is rising exponentially and 
many companies are finding that just when they 
thought they were computerized, the largist 
obstacle to improved productivity is still paper. 
Companies are taking a broader look at their 
overall processes and initiating reengineering 
programs to gain higher productivity. A common 
goal is to reduce the overall reliance on paper 
driven processes. Some of the biggest growth 
markets in business systems today are in 
automation solutions that eliminate lost time in 
processing requests and in notifying people of 
changes. The market for workflow automation 
systems, automated document imaging 
systems, and groupware are all experiencing 
tremendous growth. The equivalent to these 
office automation solutions in manufacturing is 
Product Data Management systems. According 
to ClMdata, the market for these systems is 
expected to grow at a compound annual rate of 
greater than 30% over the next three years. The 
appeal of these systems is that they don’t 
address just one or two bottlenecks, but rather 
focus on the entire process. 


Product quality continues to be one of the most 
important critical success factors in business 


today. Through the leadership of the Internatio- 
nal Standards Organisation (ISO), the ISO 9000 
standards have come to be viewed as an im- 
portant buying criteria. Buyers are looking for 
ISO certification as an indication of quality. The 
expectation is that if a supplier has its product 
process well documented and under process 
control, then the product will have higher quality. 
Data Management systems provide significant 
value in helping organizations document their 
process and later in demonstrating to auditors 
that their process is under control. 


2.5 Data Management and 
the Philosophy of Viewlogic 
Systems, Inc. 


The business approach of Viewlogic Systems 
has always reflected its “best-in-class” 
philosophy that recognizes the need for electrical 
engineers to mix and match the best tools for a 
given job, regardless of who supplies them. The 
company has long been a leader not only in 
supporting the adoption of industry standards 
through its active participation in groups such 
as CFI, IEEE and EDAC, but also in the 
implementation of those standards. For 
example, Viewlogic Systems was the first EDA 
company to offer both EDIF (IEEE standard for 
schematic exchange) and SCHEME (CFI 
scripting language) compatibility in its products. 
It was the first company to provide a fully CFI 
compliant design representation. Rather than 
creating a new behavioral simulation modeling 
language, Viewlogic Systems was the first EDA 
company to offer VHDL. The company was also 
an early adopter of the MOTIF standard for user 
interface. 


Viewlogic Systems believes that the data ma- 
nagement technology required to store and 
retrieve data is outside the realm of EDA. 
Therefore the technology of any number of 
external data management companies may be 
employed within the design process. The aim 
of Viewlogic Systems is to add value as a best- 
in-class EDA company. As such, we make no 
assumptions about where the data is located, 
how to access it and we provide a totally open 
environment that supports the management of 
data, independent of which company tools were 
used to generate it. 


The most recent advancement of Viewlogic 
Systems in the area of open systems has been 
with the release of its PowerCODE suite of 
capabilities. PowerCODE, an acronym for 
Customizable, Open Design Environment is 
designed to support the interoperability of dis- 
parate design tools. It is the architectural layer 
on which all tools are developed, and mirrors 
the best-in-class business model. Keeping vith 
the spirit of PowerCODE, the data management 
technology has been designed so that the data 
to be managed may be used by any tool, whether 
developed by Viewlogic Systems, its partners, 
a third party, or an in-house capability. 


Peter Bakker 

VIEWlogic . 

Bruistensingel 126 

5232 AC Den Bosch 

tel: 073 - 6408468 

fax: 073 - 6408469 

e-mail: pbakker @ viewlogic.com 





Integrated Design Solutions for 
Desktop CAD 


De valkuilen van een complete ontwikkelomgeving voor 


Elektronische CAD. 


ledere ontwerper heeft behoefte aan een scala 
van ontwerphulpmiddelen, maar vaak verschilt 
de combinatie van die hulpmiddelen. Sommige 
ontwerpers hebben voldoende functionaliteit 
met alleen schema-invoer en handmatige lay- 
out. Wanneer er veel complexe designs gemaakt 
moeten worden kan een autorouter een efficiént 
hulpmiddel zijn. Het vooraf simuleren van aller- 
lei problemen zoals bijvoorbeeld EMI/EMC of 
temperatuur etc. bekort de ontwikkeltijd en voor- 
komt redesigns in een later stadium. Het uitein- 
delijke doel is zo snel en efficiënt mogelijk tot 
een produkt te komen. 


Hier volgt een overzicht van veel gebruikte werk- 
plek gereedschappen: 


CAE 

Schema-invoer 

FPGA / PLD design 
Simulatie Analoog / Digitaal 
Timing diagrammen 


CAD/CAM 
AutoPlacement 

PCB lay-out 

EMI/EMC regels 
Temperatuur huishouding 
Routability 

AutoRouter 

CAM 


50 


Project Management 

ECO van Schema naar PCB 

ECO van PCB naar Schema 

Versie beheer van tekeningen en PCB lay-outs 
Bill of material 

Spare-Parts list 

Administratief projectbeheer 


Er zijn leveranciers met alle functionaliteit in een 
complete werkomgeving. Keuze voor een der- 
gelijk produkt betekent ook kiezen voor de filo- 
sofie van die leverancier en daarmee een grote 
afhankelijkheid. De filosofie bepaalt in grote 
mate hoe een ontwikkelproces verloopt en welke 
functionaliteit nodig is. Vaak zijn de prestaties 
van die functionaliteit maar voor enkele onder- 
delen echt optimaal. De rest van de onderdelen 
van dat pakket zijn vaak minder goed. Soms zijn 
die onderdelen niet gebruikersvriendelijk of ze 
bieden niet voldoende functionaliteit. In beide 
gevallen is er geen sprake van een snelle en 
efficiënte werkwijze. Het gevolg is dat tijdens de 
ontwerp-fase slechts enkele onderdelen ge- 
bruikt worden van de gehele omgeving. De ge- 
bruiker moet door een lange en moeizame leer- 
curve. 


Elke ontwerper zou graag de vrijheid hebben, 
met gereedschappen van gespecialiseerde le- 
veranciers, een optimale omgeving samen te 
stellen. Voorwaarde is een goede samenwerking 


tussen de verschillende gereedschappen. Een 
aantal leveranciers brengen nu gereedschap- 
pen op de markt met een open in- en uitgangs- 
structuur zodat ze makkelijker samenwerken 
met andere produkten. Zo kan dus de optimale 
combinatie van specialistische gereedschappen 
gekozen worden. Een probleem bij toepassing 
van specialistische gereedschappen kan ont- 
staan door verschillen in de databases van de 
ontwerper en de board-ontwerper. Door de be- 
schikbaarheid van nieuwe gereedschappen 
wordt ook dit op elkaar afgestemd. 


De ontwerper kan bij de invoer van het schema 
al veel informatie invoeren voor de lay-out fase. 
Zo kunnen er al in het schema de spoorbreedtes, 
de clearances en door de gebruiker gedefini- 
eerde attributen worden ingevoerd. Clearance 
regels kunnen nu niet alleen voor de shapes op 
het pcb ingesteld worden, maar al in het schema 
kan er bijvoorbeeld al een onderscheid gemaakt 
worden tussen High Voltage, voeding, Data en 
Clock signalen, analoge en digitale netten. Dit 
maakt het voor de lay-out ontwerper duidelijk 
aan welke eisen het board moet voldoen, terwijl 
de ontwerper weet dat aan zijn ontwerp- 
voorwaarden zal worden voldaan. Deze infor- 
matie wordt natuurlijk ook gebruikt door de 
autorouter. 


Een grote bron van ergernis is de bibliotheek 
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sign syntheses ziet er als volgt 
uit: zie fig. 2 

Engineer 
Analyse van het designs logic 


ontwerp-proces. 


Het ontwerp-proces heeft alle 
valkuilen in zich die, zonder in- 
tegratie van de juiste gereed- 
schappen, heel snel zichtbaar 
kunnen worden. De traditio- 
nele designmethode, waarbij 
een ontwerper de logica ont- 
wikkelt en het schema “over de 
schutting” geeft aan de CAD 
lay-out specialist voor de rou- 
ting, is niet adequaat voor de 
hedendaagse complexe, 
supersnelle ontwerpen met 


Physical 
design 
synthesis 


-System floorplanning 
-Physical design synthesis 
-Trade-off analysis 
-Design optimization 
(SI, routability, thermal, etc) 








Designer does 
placement 
(auto/manual) 















Routing 


Post-layout analysis 


(SI, thermal, etc.) 





2-4 Iterations 
(3-4 weeks) 


Engineer checks 
placement 





Routing problems 
(2-3 weeks) 





(1-2 weeks) 


van componenten en het beheer ervan. Er wor- 
den nu mogelijkheden geboden om met slechts 
één bibliotheek te werken waarin zowel de in- 
formatie voor schema-invoer als ook voor lay- 
out zijn opgeslagen. Dit geeft de ontwerper de 
mogelijkheid om bijvoorbeeld al bij het invoeren 
van een schema op te geven welke behuizing 
gebruikt wordt (DIP, SMD, TSOP, PLCC etc). 

Het werken met specialistische gereedschap- 
pen van verschillende leveranciers is tegenwoor- 
dig zeker een optie. De produkten sluiten goed 
op elkaar aan en bieden dus de mogelijkheid 
alleen de voor de eigen werkwijze benodigde 
gereedschappen aan te schaffen. In de volgende 
opsomming staan een aantal veel gebruikte tra- 
ditionele gereedschappen gerubriceerd en een 
moderne geintegreerde oplossing. Het traditio- 
nele ontwerp-proces ziet er als volgt uit: zie fig. 
1. Het moderne ontwerp-proces met physical de- 


Performance problems 


een hoge dichtheid. Dit resul- 
teert in veel iteratief werk tus- 
sen ontwerper en board-ont- 
werper om een optimaal com- 
promis betreffende alle rele- 
vante eisen te verkrijgen. Er 
dient rekening gehouden te 
worden met EMI/EMC regels, 
snelheid, oppervlakte, 
routability en produceerbaar- 
heid van het board. Deze 
iteraties verspillen tijd en ver- 
lengen de ‘Time To Market’. 


De juiste combinatie van ge- 
reedschappen heft de ‘schei- 
ding’ tussen CAE en CAD op. 
Met moderne gereedschappen 
kan snel een synthese lay-out 
gemaakt worden van de CAE 
data. De invloed van fysische 
factoren op de prestaties van 
de lay-out kunnen zo bepaald 
worden. Er kan geoptimali- 
seerd worden voor: produceer- 
baarheid, temperatuur, EMI/ 


EMC etc. Er ontstaat zo een betere controle op 
de voortgang en kosten van een project. 

Door de scheiding tussen de design disciplines 
weg te nemen wordt één van de grote barrières 
van elektronica ontwikkeling aangepakt. Ont- 
werp-processen worden zo bekort, de Time To 
Markt verkort, kosten verlaagd met een kwalita- 
tief beter produkt. 

Mocht om mechanische of lay-out technische 
redenen een andere behuizing voor een com- 
ponent nodig zijn, dan moet die informatie wor- 
den teruggecommuniceerd aan de ontwerper 
zodat het ontwerp ook de juiste informatie be- 
vat. Dit moet dus met gereedschappen die in de 
omgeving van alle betrokkenen bij het tot stand 
komen van het ontwerp beschikbaar zijn. 

Een goed bibliotheek beheerssysteem biedt de 
mogelijkheid de grafische presentatie van zo- 
wel schemasymbolen als pcb-footprint te bekij- 
ken. In deze presentatievorm kunnen zowel pin- 





nen als pads gewijzigd worden, wat de efficiën- 
tie zeer ten goede komt. Ook zijn er verbindin- 
gen naar tekstverwerking, DTP en Mechanische 
CAD pakketten etc. Door een pakket te kiezen 
dat gebruik maakt van de door Windows gebo- 
den faciliteiten wordt de efficiëntie vergroot en 
het gebruiksgemak verbeterd. 


Vaak zijn de gebruikers van schema-invoer en 
PCB lay-out pakketten ook kundig in het zelf 
maken van software. Dat heeft er toe geleid dat 
er een DataBase eXchange (DBX) gereedschap 
beschikbaar is gekomen om eventuele, zeer 
specifieke gebruikerseisen te honoreren. Met 
deze DBX gereedschappen kan de gebruiker 
informatie uit de design database halen, wijzi- 
gen en er zelfs informatie aan toevoegen. 


Rob Strik 
Tech 5 
Tel: 0184-615551 





When does Design-for-testability 
make Sense? 


You are a designer so you don’t have much to do with testing. As usual, the production 
department will take care of test program generation and the testing of the products you 
have designed. The test methods they use now such as Functional or In-Circuit Testing 
(ICT) are OK, but there are some clouds appearing on the horizon. More and more test 
engineering people are chasing you for Design-For-Testability (DFT) provisions in your 
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design, because nowadays 
new technologies such as 
complex devices with high 
pin-counts and also new 
types of packages (Ball- 
Grid-Arrays, SMT, etc.) mean 
they are faced with 
enormous test feasibility 
and access problems. 


WHAT ARE | IMITATIONS IN PRESENT 
PCR TESTING METHANS?? 
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One of the possible provisions they might have 
asked for is Boundary-scan, also known as IEEE 
Standard 1149.1 ‘Test Access Port (TAP) and 
Boundary-scan Architecture’. As a designer you 
have probably read about it in the magazines, 
but for your designs it is perceived as not 
applicable due to lack of devices supporting 
Boundary-scan or it is considered to only add 
extra costs and effort. 

Suddenly, it happens that the devices you are 
using apparently do have boundary-scan (or 
JTAG as some IC vendors name it). Examples 
are the PowerPC’s of IBM or Motorola, 
Programmable Logic Devices from AMD, Altera, 
Xilinx or Lattice, or DSP’s from Texas 
Instruments, Analog Devices or AT&T, or ATM 
devices from Fujitsu or Brooktree. And there are 
many more examples. Now, not only do you have 
an excellent opportunity to satisfy the testability 
needs of your production department, but also 
you can use these same facilities in debugging 
your first prototypes, resulting in much shorter 
development times. What’s more you may even 
be able to program your PLD’s on the board via 
the boundary-scan chain. 

To become more acquainted with the subject 
boundary-scan, the next chapters of this booklet 
will discuss the reasons for introducing 
boundary-scan, by reviewing Functional and In- 
Circuit Test, the provisions that are necessary 
on board level and the benefits boundary-scan 
can bring to your company. 


4.2 History of Testing 

Functional testing is the “oldest” way of testing 
electronics. In the early days of the electronic 
industry many electronic systems were simply 
assembled, and the power was switched on. By 
checking the function of the system the “test” 


EVMI TION IN TEST METHONS 


Binundary. 
Sran Tact at 
PER and 


Suetem I avol 





AN-HAC NET 


| NAPET 


[ner papt onenean E) 


1970 1075 rogn 1ORs roon zaan 
DET = NEGIGN FOR TESTARI ITV 


RENES 


THEMA: Electronic Design Automation 


was performed. Nowadays some companies still 
have to work in this way. However growing 
complexity of systems has made test preparation 
a lengthy job while the fault coverage of such 
test programs remains unknown. Functional test 
diagnostics also requires highly skilled 
technicians in manufacturing. For this reason 
testing on Printed Circuit Board (PCB) level 
evolved. Testing was still performed in a 
functional way, but by dividing the problem, one 
could conquer ! But again the quickly increasing 
complexity of Integrated Circuits (IC) caused the 
same type problems as encountered at system- 
level functional testing i.e. that of long test 
preparation times, uncertain fault-coverage and 
poor diagnostics. 


Next on to be widely adopted was In-Circuit 
Testing. By providing direct access to the 
entities to be tested on a PCB by means of a 
mechanical bed-of-nails fixture it was possible 
to test for manufacturing faults. This technology 
was well suitable to Dual-In-Line (DIL) 
packages and Plated-Through-Hole (PTH) 
PCB technology. But along with newer fine-line 
PCB-print technology and more complex IC- 
packages, such as SMT QFP’s or BGA's with 
higher pin-counts and smaller pitches, the 
clouds in the test sky appeared nearer. Fixturing 
technology couldn’t keep up with the ever 
decreasing dimensions of pins and pitches and 
the higher pin-counts of packages . Finally, as a 
result of industry co-operation which anticipated 
many of these problems, the boundary-scan 
method evolved as IEEE Standard 1149.1 Test 
Access Port (TAP) and Boundary-Scan 
Architecture. By 
using this technique for testing many of the 
predicted draw-backs of the other test 
technologies could and would be overcome. 


Following this evolution in testing methods a 

number of observations can be made: 

- Design-For-Testability (DFT) has not always 
been an issue. It started to become impor- 
tant with functional board testing in order to 
increase ad-hoc controllability and 
observability of the function for test. However 
for testing today’s designs DFT is inevitable. 


- Initially testing was a mixture of design debug 
and detecting manufacturing faults. Nowadays 
separate disciplines exist for design 
verification and manufacturing testing. Both 
ICT and Boundary-Scan Testing (BST) are 
well focused on finding manufacturing faults 
such as opens solder shorts, stuck at failures 
or missing/wrong components. 


FUNCTIONAL TEST CHARACTERISTICS 
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4.3 Functional Test 


There are two draw-backs of testing in this way: 
Firstly, the preparation of the test program itself 
is vulnerable to changes in the design. As a 
consequence of a smalldesign change the 
whole test development effort might be 
wasted. Furthermore, a functional test pro- 
gram is not focused on manufacturing type of 





faults which might end-up giving poor fault 
coverage. Also the fault coverage of a 
functional test program is not known, unless 
cumbersome fault simulators are used. 


The second drawback lays with the diagnostics. 
Due to a lack of automated tools diagnostics 
are generally prepared by the designer (as is 
the test program), since this person is the most 
knowledgeable on this design. 

However the designers time is a scarce resource 
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and it is not often feasible to generate a 
precise, down-to-the-pin level, diagnostics 
routine, since that would take too much time. 
The result is an imprecise and lengthy dia- 
gnosis that will require trial and error repair 
methods. This will in turn impact in a negative 
sense on the quality/reliability of the delivered 
products. Alternatively if time limits are set to 
the repairs the result could be a pile of scrap- 
boards with unresolved problems waiting for 
re-work time capacity that never comes. 
Ultimately a waste of capital! 


4.4 In-Circuit Testing 


In-Circuit Testing evolved as a test method to 
overcome the functional test problems. By the 
use of standard sets of test vectors for each 
component it was easy to generate a test pro- 
gram well focused on the detection of 
manufacturing faults. Furthermore in ICT 
diagnostics is achieved directly on the compo- 
nent level. In order to realise the advantages of 
this test method a so-called bed-of-nails fixture 
has to be used. This type of fixture also has some 
negative points and as technology the negative 
points become drawbacks that make the use of 
this method impossible. Consider the following. 


Firstly, the bed of nails gives mechanical and 
logical access to internal logical states. This 
intrusion in the logic, called back-driving, may 
have impact on the quality/reliability of the PCB, 
because if done incorrectly devices are used 
outside their specifications. In the manufacturing 
process these fixtures are a source of constant 
irritation for the management due to bad con- 
tact reproducibility. An unreliable throughput 
figure makes planning impossible! 

The advent of ASICs and VLSI has also 
condensed the advantages of the “standard test 
vector sets”. By not having the libraries for these 
devices available, or by receiving them late, ICT 
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was performed without them by simply using 
(empty) sockets. However the final blow for ICT 
within production came with the introduction of 
new IC packaging technologies such as Surface 
Mount Technology (SMT), Ball-Grid Arrays 
(BGA) and new assembly techniques such as 
Multi-Chip Modules (MCM), Flip-Chip, Chip On 
Board (COB) or Tape Automated Bonding (TAB). 
All these new technologies make the mechanical 
access as required for ICT prohibitive. For this 
reason the industry invented a new answer to a 
new problem: Boundary-scan testing. 


4.5 Test Access Review 


To understand the solution offered by boundary- 
scan, let's first analyze the basics of testing in 
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relation to test access. This can then be 
compared with the test access used by the 
various other test methods. 


For testing digital logic (“cluster”) logical values 
(1’s and O's) are applied to the inputs of a clus- 
ter and the response of the cluster in “1”s and 
“O”s has to be observed (see figure on page 7). 
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The response is then compared with the 
expected values at the outputs, in order to judge 
whether the test has passed or failed. The 
function of the logic comprised in the cluster 
could be simply wiring, a single IC, or a group of 
IC’s. The fact remains that the “TEST” of such a 
cluster is independent of the test access method 
used. Thus, irrespective of the test methods 
used, it is only the access to the inputs and out- 
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puts of the logic cluster which is provided in 
differing ways. Let's explain. 


Within a functional test the cluster to be tested 
is embedded in other logic. Suppose then that 
in the functional test the edge-connector is the 
only connection to the tester. Therefore, all test 
vectors have to be applied from the edge con- 
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nector such that the intended test patterns 
appear at the inputs of the “cluster to be tested”. 
It is that transformation which is the principle 
difficulty in the test preparation and can only be 
done with the knowledge of designer, or by a 
(fault)simulator. In the same way it has to be 
known what the expected output values will be 
at the edge connector. Again, this job can only 
be done efficiently by the designer (including the 
diagnostics in case the fault appearance is 
wrong), or by a (fault) simulator. Notice however 
that the “TEST” as such is independent of the 
surrounding function! 


For In-Circuit Testing the test access to the “clus- 
ter to be tested” is quite crudely provided by the 
bed-of-nails fixture. Moreover the foot prints of 
clusters may vary from board to board type, often 
requiring specific fixturing per board. From the 
nails of the fixture wiring then connects the “test- 
points” to the actual ICT. For testing at high 
speeds this wiring is subject to the same de- 
sign rules as must be applied to tracks on the 
PCB's in order to prevent problems such as 
cross-talk, ringing, etc. However, in practice use 
of such design rules in the preparation of pin- 
beds is often ignored leading to severe test 
debug problems. Notice though that the “TEST” 
itself is once again independent of the usage of 
a pin-bed. 


4.6 The Boundary-scan 
Solution 


In cases where the “cluster to be tested” is 
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embedded by boundary-scan chains (on the 
PCB, or external of the PCB), test access can 
be provided via these chains. The test data is 
first shifted in serially from the tester, once the 
serial shift has been completed the test vectors 
are applied in parallel to the cluster inputs (“UP- 
DATE-PHASE”). The results of the test at the 


cluster outputs can then be parallel loaded in 
the boundary-scan chain (“CAPTURE-PHASE”) 
and serially shifted-out to the tester, a 
comparison of actual versus expected data will 
be used to determine whether the test was a 
PASS or FAIL. Notice that the “TEST” as such is 
independent of the usage of Boundary-scan as 
an access method. 

What's more the test vectors are still assigned 
to signal names (nets) in a design, for instance 
for ADO.....AD5 apply 110010 and at DO...D5 
observed values are 001101. 

Q:-Is it difficult to perform such a “test” with 

access via BST-chain ? 
A:- NO, not at all, because the test remains 
described at the (parallel) signal level! 

The reason is that the whole “machinery” of 
shifting-in and shifting-out according to the IEEE 
1149.1 Boundary Scan protocol can be 
automatically performed by the software tools 
from JTAG Technologies. As a user you don’t 
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have to know all the in depth details, simply 
specify at net level the logic level you want to 
drive or expect to sense. It sounds unbelievably 
simple, but in our daily life we have similar 
examples. For instance, compare it to our 
telecommunications infrastructure. When you 
call someone to pass a message(10111) you 
don’t want to be bothered with all the ISDN 
protocols involved just as your receiving party 
doesn’t. The same applies with boundary-scan 
testing. JTAG Technologies SW takes care of 
transporting your vectors to the nets in your de- 
sign and then the Vector Interface Package SW 
(VIP) reports the response of the test at net le- 
vel to your computer. 


4.7 What’s Needed to Get 
Boundary-scan Access? 


It would take too much silicon and cost over- 
head to specifically design-in a boundary-scan 
chain by using separate components. 
Fortunately, that’s also not needed! Most IC-ven- 
dors have boundary-scan already built-in to their 
parts. Examples are found at Intel with 486, 
Pentium, Pentium Pro, 386 EX for embedded 
application, Motorola and IBM with the various 
PowerPC versions , Motorola with 68k family, 
Texas Instruments with DSPs, Sparc and buf- 
fers, and bus logic, National Semiconductor with 
buffers, AMD with 29k, Mach 4/5 , Digital with 
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the Alpha chips and many others. Ask your JTAG 
Technologies’ sales representative for the free 
of charge “Boundary-scan Parts Shopping List”. 
Moreover (and contrary to popular belief), it is 
not absolutely necessary to have all devices 
equipped with BST. For example during the re- 
view of access to the “cluster to be tested” (see 
Chapter 4) cluster components could easily be 
non-boundary-scan parts! What's more, there 
are several industry examples known, where 
from just one BST device, an entire PCB could 
be controlled and observed and thoroughly 
tested (including memories !!). 


To utilise the boundary-scan in your design is 
also a simple matter. Whether you have selected 
boundary-scan components intentionally or by 
accident, all that is required is for the chain(s) to 
be connected at the start of your design. Firstly 
each boundary-scan data output pin (“TDO”) has 
to be connected to a next boundary-scan data 
input in (“TDI”) and for control of this ‘test ma- 
chine’ which includes the shifting operations etc.. 
each boundary-scan device has to be connected 
to the test clock (“TCK”) and the test mode se- 
lect (“TMS”) signal. As for the other logic 
functions, normal design rules apply for the lay- 
out! 


4.8 What Can You Do With 
Boundary-scan? 


Boundary-scan was invented to overcome the 
manufacturing test problems evolving from In- 
Circuit Testing and use of SMT devices. The 
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several test steps that can be conducted via 
boundary-scan will be discussed further in 
Chapter 8. 

However it has turned out that manufacturing 
testing wasn't the only application for this serial 
bus. Due to the easy access, the ease of test 
preparation and the low costs of the tools it is 
often successfully applied in testing prototypes 
for manufacturing faults. Without boundary-scan 
facilities this process may take several days or 
even weeks, consuming the scarce time of the 
designer. Furthermore by using boundary-scan 
the prototype test can be performed by 
production personal, since no special knowledge 
is needed about the logic functions of the PCB. 


System level testing is another example of anew 
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application area for boundary-scan. By 
extending the chains to the back-plane test 
access to the PCBs from system level can be 
achieved. There are different ways to implement 
boundary-scan at system level. In order to geta 
minimum overhead of chains, the ScanBridge 
of National Semiconductor or the ScanPath Lin- 
ker and/or the Addressable Scan Port (ASP) of 
Texas Instruments are often used. System test 
execution can also be performed from an 
external tester or from internal system logic as 
an embedded test. Several solutions are already 
available in the market to support these 
applications. 
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To increase the reliability of electronic systems 
early life failures can be weeded out by burn-in. 
At higher temperatures the PCBs are operated 
in order to accelerate the infant mortality period. 
During this period early failures should show- 
up. Common practice is for faults induced during 
the burn-in to be detected at room temperature 
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using production test equipment such as In- 
Circuit Testers. Unfortunately this test will not 
always reproduce the same fault as detected 
during accelerated burn-in. The explanation is 
simple: when cooling down the PCB opens in 
solder joints will make a connection again at 
lower temperature or even will be forced to a 
connection by the bed-of-nails fixture. With the 
use of boundary-scan the effectiveness of the 
burn-in can be drastically enhanced by 
preventing these situations: even at elevated 
temperature it is possible, due to the simple four 
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wire (plus power supply) interface, to run a test 

and to perform full diagnostics! 

One of the latest, but not the least (and certainly 

not the last !) new application of boundary-scan 

is In-Circuit or In-System programming of PLD’s 
via the boundary-scan chain. The advantages 
are numerous: 

- in engineering easy reprogramming of the 
PCBs during firmware development and 
verification 

- in the production less logistic overhead and 
handling 

- flexible customizing of the products at the latest 
possible stage in the production 

- testing and device programming as one action 
using the same (test) equipment via the same 
connector. 


4.9 Test Application 
Sequence Example 


Testing your tester 

The first step in the boundary-scan test process 
is the testing the infrastructure of the boundary- 
scan chain(s). Clearly before you can conduct 
any other test on your Printed Circuit Board, you 
should ensure that the boundary-scan path is 
working correctly. In the figure you see an 
example of a boundary-scan infrastructure that 
can be subjected to testing. 


fact, the boundary-scan chain(s) can be seen 
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as an extension of your tester. For this reason 
the boundary-scan infrastructure test is always 
recommended to be performed first. 


Interconnection Testing 

The next step in the boundary-scan test process 
is the test for all boundary-scan testable 
interconnections (nets) of your Printed Circuit 
Board. 

A net is considered to be Boundary-Scan 
testable if the net can be accessed by boundary- 
scan cells of devices on the board and/or by the 
parallel connector pins of the board. With mo- 
dules like general purpose I/O modules, paral- 
lel access to the connector pins of a board is 
realized. 

In this interconnection test a wide variety of net 
terminators such as drivers, sensors, tri-state 
outputs, bi-directional pins, differential nets and 
parallel I/O can be covered. 


Giving Test Access to Clusters 

Until recently the boundary-scan chains on a 
PCB or MCM could only be used to test 
interconnections between digital components 
equipped with boundary-scan cells. However, the 
boundary-scan chain(s) in a design can be 
utilized for far more than just interconnect test 
applications. By re-using existing boundary-scan 
chains in your design, test access to a group of 
non-boundary-scannable parts (so-called clus- 
ters) can easily be provided. In the figure you 
will find examples of a Printed Circuit Board with 
different types of clusters. In this way testing for 
typical manufacturing faults such as bad solder 
joints, solder bridges or defective components 
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on PCBs or defective wire bondings on MCMs 
inside a cluster is becoming feasible. Typical 
clusters could be static or dynamic memory 
devices, FIFO’s, PLD’s or random logic. 


The presence of just one boundary-scan com- 
ponent (e.g. a microprocessor) on your board 
providing access to those devices, is already 
enough to make a memory test possible. All this 
for testing random access memories, for testing 
clusters of components or for verifying the 
function of PLDs during prototype debugging or 
manufacturing. 


Special Cluster type: Memory Testing 

For specific clusters consisting of static or 
dynamic memory devices, or FIFO’s, the tedious 
task of manually creating functional tests and 
the associated design specific diagnostics rou- 
tines has become a thing of the past with JTAG 
Technologies advanced Test Pattern/Program 
Generation (TPG) software. All test vectors for 
memory clusters can be generated 
automatically. All possible manufacturing defects 
such as bad solder joints and solder bridges for 
PCBs will be detected using these test patterns 
and all address lines, data lines, and control lines 
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in such RAM clusters are thoroughly tested. In 
addition a fault dictionary can be generated 
containing all the necessary information for full 
diagnostics. 


4.10 Commercial Benefits 


a) Time-to-market is shorter 
The impact of time-to-market has been most 
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recognized after the publications of the 
Mackinsey study and other studies. These 
publications reveal that on-average there is a 
reduction of 33% in the after-tax profit when 
products are shipped six months late as 
compared to a 3.5% reduction of the same pro- 
fit when the product development expenses are 
overspent by 50%. Also, the faster a product is 
introduced into a competitive market, the larger 
potential life time it will have and hence the 
greater its return on investments is. Boundary- 
scan improves, in various ways, the time-to- 
market of a product: 


Concurrent Engineering 

The introduction of Boundary-Scan Test (BST) 
favours the introduction of concurrent enginee- 
ring. It should be made clear that concurrent 
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engineering can be introduced without BST, but 
BST further increases the advantage. In any 
case, the main reason to introduce concurrent 
engineering is, of course, to get the right product, 
at the right time, for the right price, onto the 
market. 


For concurrent engineering a project team is put 
together with engineers from various disciplines 
and such a team is continuously supported by 
the management. Since the team members meet 
at regular, say weekly, intervals the internal 
communication will prevent redesigns due to 
design errors or due to insufficient design 
verification. As a result, large cost savings are 
made during production, earning back many fold 
the extra time spent in the design phase. If a 
redesign is unavoidable, then it should be done 
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so as to fit the design into the current 
manufacturing process rather than adjust this 
process to the new design. In this way 
unnecessary costs are avoided. Finally, 
designers are encouraged to cooperate in the 
new product or project right from the beginning, 
when the proposals are put forward by the mar- 
keting department. In fact, this also gives quality 
improvements. Due to the encouragement, the 
designer may be more inclined to added more 
value to the product. 


It should be noted that BST inherently supports 
concurrent engineering since the designer is 
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concerned with the whole product life cycle. 
Furthermore it has been concluded that concur- 
rent engineering shortens the development 
times and that BST does so even further, through 
which the shortest possible time to market is 
obtained. 


Reduced Time for Prototype Debugging 

The types of faults the designer is confronted 
with during debug are design faults (obviously), 
and also manufacturing related such shorts and 
opens. However, in supporting the designer, the 
investments in specialized or dedicated test 
equipment are usually kept as low as possible 
because when the design is ready, part of the 
equipment becomes obsolete and remains 
unused. Moreover, the designer can only 
perform functional tests that are mostly 
ineffective due to poor fault coverage. 
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The solution is BST. As shown in the above figure 
the test programs for manufacturing faults can 
be easily ready in time to help the designer to 
debug the PCB prototype. This is especially 
beneficial in the design of large systems where 
considerable numbers of prototypes are required 
for the further development of the system soft- 
ware or the hardware/software integration. This 
reduction of this critical path length contributes 
greatly in meeting the time-to- 

market objectives. 


Reduced Production Ramp-up 

It frequently occurs that a commercial plan 

cannot be kept due to start-up problems in the 

factory. The assistance of the designer is then 
requested, which is inefficient in at least two 
ways: 

i) the dedicated test equipment of the designer 
is not suited to support a production line 
efficiently and 

ii) the designer does not like to do work for which 
he is not trained and certainly not if that work 
is below his skills. 


Moreover, such a working method does not 
guarantee high quality and it leads to overspent 
budgets. Once again, the figure on page 18 
demonstrates the value of applying BST as the 
availability of BST test patterns before 
prototyping starts ensures that prototype 
production and test preparation are completed 
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well within time. 


b) Lower costs 

Lower Capital Investments 
It has become clear that the introduction of 
Boundary-scan Test technology also implies the 
application of DFT and concurrent engineering. 
As a consequence the efforts in the design 
phase have to be increased. Computer power 
for the software developers also requires 
considerable investment, in addition to the 
personnel costs. In order to obtain the highest 
added value from the designers, they should be 
equipped with CAD/CAE workstations and 
supporting software packages. 

These computer costs may easily be millions of 
Dollars, but in any case they are needed for 
design activities. The point is to exploit these 
tools to their full extent and not just for the de- 
sign project. These tools should support both 
DFT for ICs and/or PCB designs (preferably 
automated) and test preparation activities for 
which the automatic inputs of the CAD/CAE sta- 
tions are very important for fault free test 
generation. For instance when the boundary- 
scan test pattern generation SW tools are resi- 
dent in the design environment then schema- 
tics input or the netlist files required (in EDIF) 
can immediately be used to investigate the 
testability and to get an first test program. This 
will also avoid the tedious manual data entries, 
thus assuring the quality of data transfer. 

The introduction of BST will further reduce the 
investments for testing, particularly 
in the manufacturing phase of the 
product life cycle. 


This reduction has two causes: 
i) The price of the BST tester is 


due to higher fault coverage achieved during the 
various test phases. 


Technology compliance 

The products i.e. the Device-Under-Test (DUT) 
and the test equipment used are by definition 
in the same technology, because BST is 
incorporated in the logic of the functional de- 
sign. There is never a mismatch or divergence 
of technologies as can happen in the case of 
bed-of-nails systems where a conflict has 
occurred between fixture engineering and the 
shrinking device sizes and novel packaging 
technologies. These conflicts can clearly 
influence the quality of testing and consequently 
the product quality. 


In time availability manufacturing tests 
There is no ad-hoc testing in the starting-up 
phase of manufacturing, because with BST test 
preparation lead times are short and in time due 
to Concurrent engineering possibilities. 

With Functional or In-Circuit Test techniques 
programs are often not available in time or not 
at the right level with respect to fault coverage. 
The impact of these realities on a customer’s 
expectations and your brandname and service 
costs can be disastrous for the long-term growth 
of your company! 


Quality of test and diagnostics 

The very high fault coverage of the BST test and 
the high degree of diagnostic capabilities lowers 
the slip through rate of faults during the 
manufacturing phase resulting in a better 
product quality and reliability. 


4.11 Does Boundary-scan 
Make Sense to You? 


If you don’t currently have a problem with testing 
or programming either from a feasibility or a cost 
point of view, then please regard the contents 
of this booklet merely as informative. 

However, if some of the problems encountered 
during testing or programming sound familiar to 
you and you are looking for a solution, boundary- 
scan will make sense to you when one or more 
of the following points apply to your situation: 
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much lower than that of a 
traditional ICT tester: The prices 
come down from hundreds to 
tens of thousands of Dollars. 
One of the reasons for this is the 
number of test pins (nails) 
required : a multiple of 5 (for 
example 25 in a five TAP tester) 
is used in the BST case and 


thousands in the ICT case. fom 





What’s more, since BST testers 
are highly SW-intensive, they 
are liable to future price 
erosions. 

ii) For BST less testers are needed 


due to shorter fault diagnosis geen 
times, through which the factory Ne 
throughput per tester is ia 
increased. 


c) Improved product quality and reliability 
Mandatory design rule 

Making Boundary-scan mandatory as a design 
rule to enhance the Design-For-Testability 
means that the designers have to think 
beforehand about the problem. The experience 
teaches us that innovative solutions are created, 
which would have been impossible if these had 
to be built-in afterwards. These phenomena will 
contribute to the improvement of the quality and 
reliability of the electronic products and systems 
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or Texas Instruments’ or Analog Devices’ or 
AT&T's DSP’s 

-telecomm/datacomm devices such as for ATM 
from Fujitsu or Brooktree, or as for Ethernet 
from National Semiconductor or AMD 

b) you want to perform In-Circuit or In-System 
Programming of (C)PLD’s or FLASH memory 
devices in your factory and you want to 
simplify logistics around the programmable 
devices 

c) you do have problems with physical access 
(fixtures) with ICT due to fine pitch Surface 
Mounted Devices or other complex package 
types 

d)you are only using functional testing because 
the ICT-methodology is too expensive for the 
(low) number of boards in your activity 

e) your costs and development time for fixtures 
and In-Circuit Testing programs are becoming 
outrageously high 

f) your HW designers hate to spent (too) much 
time on debugging prototype boards due to 
production faults 

g) your engineers don’t have time to spent on 
designing functional tests with good coverage 
for production faults 

h) you want to re-use the efforts in time and 
investments spent on testing during the pro- 
totype debugging phase for manufacturing 
testing and for service testing 

i)your activity is: 

- a small and medium size electronics company 
- a (small) department or activity in a large 
company such as prototype production or a 


project organization - an engineering/ 
instrumentation department of Institute/ 
University —\ 


- an engineering department of non-electronics 
(production) company 

j) Time_To_Market of your products is vital for 
your company 

k) meeting (international) project deadlines / 
milestones is very important for your 
organization. 

I) you do have too many scrap boards in your 
production: boards that can not be repaired 
due to lack of diagnostics 

m)required quality of your products don't allow 
iterating repair actions. 


If one or more of above points are 
valid for your situation you might 
consider boundary-scan as an 
applicable solution for your 
problems. With just one boundary- 


ash N 


— may already be able to circumvent 


many of above mentioned problems 
and easily achieve test or program- 


C mre ming applications. 


for Tactine 


\SPAM nr DRAM / 


Besides the boundary-scannable 
devices also static or dynamic me- 
mories can be tested, 
programmable devices such as PLD 
or FlashProms can be in-system 
programmed via the chain! For 
smaller companies or institutes or 
company department that cannot 
afford the capital investment of an 
In-Circuit Tester and still are 





a) you do have one or more devices in the 
design available with boundary-scan e.g. 

- your own ASIC(s) designed with boundary- 
scan 

-complex PLD’s such as AMD MACH 355/445/ 
465, Altera EFX740/780 /880 /8160, 
MAX7000/9000 series, Xilinx XC4000, 
XC5200, XC8100, or XC9500, or Lattice isP’s 

- complex (32-64 bit) processor chips such as 
Motorola’s PowerPC or 68k, or IBM’s 
PowerPC, Intel's 386EX, 486, Pentium (Pro), 


TTA C 


struggling with functional test, 
boundary-scan offers a low cost, 
(typical a factor of 10 lower) test 
solution for finding manufacturing 
faults. Also as a test technique suitable for field 
service, boundary-scan is opening new 
horizons. Time to market is nowadays becoming 
more and more important because product life 
cycles are decreasing continually, even to below 
one year. If time to market is important to you, 
boundary-scan will help. Due to its very short 
test preparation time fixtureless test access and 
early availability it contributes in the reduction 
of the prototype debugging phase and is always 
available in time for production testing. 
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4.12 For more information 

1) IEEE Standard 1149.1-1990, Test Access Port and 
Boundary-Scan Architecture, revision IEEE 
Standard 1149.1a-1993 and Supplement IEEE 
Standard 1149.1b-1994, published by the Institute 
of Electrical and Electronics Engineers, Inc., 345 
East 47th Street, New York, NY 10017, USA. 

2) Boundary-Scan Test - A Practical Approach, 
Bleeker, van den Eijnden, de Jong, published by 
Kluwer Academic Publishers, P.O.Box 17, 3300 AA 
Dordrecht, The Netherlands. 


4.13 Glossary of Abbreviations 

ASIC Application Specific IC 

ASP Addressable Scan Port 

ATM Asynchronous Transfer Mode 

BGA Ball Grid Array 

BSDL Boundary-Scan Description Language 
BST Boundary-Scan Test 

CAD Computer Aided Design 

CAE Computer Aided Engineering 

COB Chip On Board 

DFT Design For Testability 

DIL Dual In Line 

DSP Digital Signal Processor 

DUT Device Under Test 

EDIF Electronic Design Interchange Format 
FIFO First In First Out 

IC Integrated Circuit 

ICT In Circuit Test(ing) 


IEEE Institute of Electrical and Electronics 
Engineers 

ISDN Integrated Services Digital Network 

JTAG Joint Test Action Group 

MCM Multi Chip Module 

MTBF Mean Time Between Failures 


PCB Printed Circuit Board 
PLD Programmable Logic Devices 


PTH Plated Trough Hole 

QFP Quad Flat Pack 

RAM Random Access memory 
SMT Surface Mount Technology 
TAB Tape Automated Bonding 
TAP Test Access Port 

TCK Test Clock 

TDI Test Data Input 


TDO Test Data Output 

TMS Test Mode Select 

TPG Test Pattern (or Program) Generation 
TRST Test Reset 


VIP Vector Interface Package 
VLSI Very Large Scale Integration 


Testimonial 
For Parsytec GmbH Boundary-Scan did make sense: 
“Since December 1994 we have been working in 
manufacturing using boundary-scan testers from JTAG 
Technologies B.V. With the JTAG Technologies’ test 
system, prototype tests for Printed Circuit Board <type> 
are performed. This has been very simple to implement 
and has been especially easy to find faults on com- 
plex PCBs. hi 
Here is an overview of the results recorded so far: 
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of which 

simple faults in memories..... 27 
miscellaneous faults............. 34 

The identification of the 34 miscellaneous faults would 
have required a considerable effort in man-hours wit- 
hout boundary-scan test facilities. By use of boundary- 
scan 29 of these faults (i.e. 85%) were detected and 
removed quickly and efficiently. The remaining 5 faults 
could be traced back as failing clocks and other easy 
to find faults. 

It must also be mentioned that without boundary-scan 


some faults couldn’t feasibly be detected because of 
the complex relationship between the PowerPC signals. 
Using conventional techniques these signals could 
have only be measured adequately with extremely 
large [test preparation] efforts. 

Also JTAG Technologies’ programming software 
(JTAGPROG) for programming AMD MACH 445 has 
used. First demonstrations showed that using this soft- 
ware a considerable speed increase in the program- 
ming could be achieved. At that time the programming 
times with the AMD software took about 50 seconds 
per device (e.g. a board with seven AMD MACH 445 
would need 6 minutes). With the software from JTAG 
Technologies it has been completed within one minute. 
With further special hardware (VectorBlaster) this 
programming time can still be drastically reduced.” 
Parsytec GmbH Germany, May 1995 


JTAG Technologies B.V. 

Author: Mr. H. Bleeker 

P.O. Box 1542, 

5602 BM Eindhoven, The Netherlands 
fax: +31 40 246 84 71 

tel: +31 40 295 08 70, or +31 40 243 32 92 
internet: info@jtag.nl 


All brand names or product names mentioned in this 
presentation are trademarks or registered trademarks 
of their respective holders. 

The figures and descriptive materials contained in this 
“When Does Design-For--Testability Make Sense?” are 
for illustrative purposes only. The contents are subject 
to change without notice. No part of this document 
may be reproduced in any form without the prior written 
permission of JTAG Technologies B.V. 

1996 Copyright JTAG Technologies B.V. 





EMC Advisor 


Een integrale aanpak van EMC tijdens het routing en layout process 


EMC ( Electro-Magnetic Compatibility ) wordt vaak door 
ontwerpers nog opgevat als een extra behuizing of een 
aantal extra onderdelen die moeten worden toegevoegd om 
het apparaat of systeem aan de gestelde EMC eisen. Dit 
heeft tot gevolg dat de diegene die het budget van het pro- 
ject bewaken de volgende misvattingen ontstaan: 


* Het kost alleen maar meer geld. 

* In het gunstigste geval blijft de werking van 
het apparaat het zelfde. 

* De voortgang van het projekt wordt door on- 
duidelijke redenen vertraagd. 


Deze misvattingen lijken in eerste instantie te- 
recht maar er zijn ook een aantal voordelen die 
spreken voor electromagnetische compatibiliteit 
van electronische apparaten. Minder ongedefi- 
nieerde storingen van apparaten die in gebruik 
zijn, 

dus: 

* Lagere service kosten. 

* Minder uitval in productie 

* Minder redesigns. 


Het is belangrijk de EMC problematiek zo vroeg 
mogelijk aan te pakken, in verband met het feit 
dat de kosten toenemen en de mogelijkheden 
tot correctie afnemen naarmate het ontwerp vor- 
dert. 


5.2 Deskundig advies met 


een druk op de knop. 

Met EMC Advisor voor Cadstar komt Zuken 
Redac tegemoet aan de vraag voor verbeterde 
Electromagnetische comptabiliteit voor printed 
circuit boards. De EMC Advisor helpt de pcb 
ontwerper om van te voren te bepalen of een 
ontwerp voldoet aan EMC eisen. EMC Advisor 
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bestaat uit een flexibele en complete set van 
regels waarmee het ontwerp gecontroleerd kan 
worden. het geeft PCB ontwerpers ondersteu- 
ning en advies over de te nemen maatregelen 
tijden het lay-out proces. De advisor laat het re- 
sultaat van de analyse zien d.m.v. staaf- 
diagrammen waarna de ontwerper de desbe- 
treffende objecten welke niet aan de gewenste 
resultaten voldoen kan accentueren. De EMC 
Advisor bestaat uit een fieldsolver, welke de 
electromagnetische vergelijkingen oplost en een 
ruleboek dat de resultaten van de fieldsolver 
interpreteert en combineert met een aantal prak- 
tijk regels. De EMC Advisor werkte geheel geïn- 
tegreerd in de Cadstar PCB lay-out omgeving 
en is al enkele jaren in gebruik op Zuken Redac’s 
Visula Expert systeem. 


Bij het ontwerpen van printed circuit boards kun- 
nen we een aantal regels hanteren die het ont- 


werp minder gevoelig maken voor EMI. Hierbij 
onderscheiden we een aantal type storingen en 
regels. 


5.3 Differentiële Storingen. 


Gesloten lussen. 

Een lus van een spoor is in principe een an- 
tenne voor EMI welke straling genereert en ont- 
vangt lood recht op het vlak. Deze regel be- 
schouwt alleen lussen welke gevormd worden 
door het spoor zelf. Gesloten lussen gebruiken 
altijd meer dan één laag en kruisen een seg- 
ment van het zelfde net. 

Deze regel wordt genegeerd in het geval dat er 
een voedingsvlak tussen de segmenten ligt. De 
mate van uitstraling loop kwadratisch op met de 
frequentie maal het ingesloten oppervlak. 


Open lussen. 

Een lus van een spoor is in principe een an- 
tenne voor EMI welke straling genereert en ont- 
vangt loodrecht op het vlak. Deze regel be- 
schouwd alleen lussen welke gevormd worden 
door het spoor zelf. Open lussen gebruikenaltijd 
meer dan een laag en kruizen niet met het zelfde 
net. De mate van uitstraling is proportioneel met 
het oppervlak maal de frequentie in het kwa- 
draat Deze regel wordt genegeerd in het geval 
dat er een voedingsvlak tussen de segmenten 
ligt 
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Afscherming van Sporen. 

Een afscherming rond een spoor geeft een lo- 
kaal retour pad voor EMI. Een scherm rond spo- 
ren reduceert ook de karakteristieke impedan- 
tie van het spoor. 





Impedantie profiel. 

Gebieden met hogere impedantie geven meer 
EMI. Het is goed om te proberen de zelfinductie 
te verlagen en de capaciteit te laten stijgen. Hier- 
door neemt de impedantie van het spoor af. Het 
eenvoudigste is het verhogen van de capaciteit 
d.m.v. een scherm of grond vlak. Deze regel test 
sporen waarvan de impedantie hoger is dan het 
gemiddelde over het board. 


XY richtingen. 

Spoor segmenten op naast elkaar liggende la- 
gen moeten haaks op elkaar staan. Dit redu- 
ceert de capacitieve koppeling van sporen op 
elkaar. Deze effekten nemen toe met hogere fre- 
quentie en snellere transitie tijden. 





Spoor Stubs. 

Stubs ( zijtakken van het hoofdspoor) geven 
ongewenste reflekties als ze een kritische lengte 
overschrijden. Dit geeft buiten additionele 
electromagnetische interferentie ook signaal 
vervorming. De Stubregel gebruikt de fieldsol- 
ver om de maximale stubdelay uit te rekenen 
waarvoor geldt dat deze niet groter dan 10% 
van de signaal stijgtijd mag zijn. 


dn dend | 


l 





Spoor resonanties. 

Als de propagatie vertraging van een spoor in 
de buurt van een veelvoud van een 1/4 golf- 
lengte nadert neemt de efficiëntie als uitstra- 
lende antenne toe. Dit geeft een stijging in de 
electromagnetische uitstraling en maakt het 
spoor ook meer gevoelig voor instraling. 
Spoor resonanties worden berekend aan de 
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hand van de frequentie en de stijgtijd van het 
signaal om een set van harmonische frequen- 
ties te bepalen waarbij de 1/4 golflengte signifi- 
cant is. 





Retour sporen. 

Retour lussen worden bepaald om zeker te zijn 
dat een signaal retour pad binnen een minimale 
afstand van het spoor beschikbaar is. Deze re- 
gel is vooral van toepassing op twee laags bor- 
den. 





Vanuit EMC oogpunt is het altijd beter een aard- 
vlak op te nemen, waarbij uiteraard de kosten 
van het board omhoog gaan, maar een betere 
controle over impedantie en uitstraling kan wor- 
den uitgeoefend. 

Deze regel detecteert sporen welke geen of te 
weinig afscherming hebben. 


— | 


« - 


Shielded By Awa Of Capper 


Shielded By Coppor On Differont Layer 


5.4 Common mode 
Storingen. 


Laag opbouw. 


De laag opbouw bepaalt voor een grootdeel de 
EMC eigenschappen van het bord, waaronder 
spoorimpedantie e.d. De gebruikte materialen 
permeabiliteit en dikte van de lagen spelen hier- 
bij een grote rol. 


Geisoleerde gebieden. 

Een veel gebruikte methode voor reductie van 
emissie is het vullen van lege gebieden met 
kopervlakken hierdoor een effektieve 
afscherming van de signalen gerealiseerd. Deze 





kopervlakken kunnen echter als uitstralers gaan 
fungeren als ze niet aan een voedingsvlak vast- 
zitten. Zwevende vlakken koppelen met sporen 
doordat ze naast het spoor liggen en kunnen 
mee resoneren met sporen. Het spoor hoeft zelf 
niet de correcte dimensies te hebben om een 
naast liggend vlak dat wel de juiste dimensies ( 
veelvoud van 1/4 golflengte ) heeft in resonan- 
tie te brengen. 





Overlappende vlakken. 

Sommige ontwerpen maken gebruik van ver- 
schillende voedingsvlakken met verschillende 
spanningsniveaus. Het is in de praktijk niet ge- 
wenst deze vlakken te laten overlappen. Het 
overlappen van deze vlakken kan leiden tot on- 
gewenste systeemruis. Het overlappen van cor- 
responderende vlakken is echter wel gewenst ( 
bv. +5V en GND ) omdat dit de ontkoppelcapa- 
citeit van de vlakken verhoogt. 





Component plaatsing. 

Snelle componenten moeten zo dicht mogelijk 
bij de voedingsbron geplaatst worden om 
transienten te verminderen. Voor borden zon- 
der voedingsvlakken vormen de voedingssporen 
een signaallus, door snelle componenten zo 
dicht mogelijk bij de voedingsbron te plaatsen 
wordt het lusoppervlak kleiner en dus de uitge- 
straalde energie minder. 


Dit algoritme berekent de ideale afstanden voor 
ieder component en signaleert componenten die 
significant van deze plaats afwijken. 
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Ontkoppeling. 

Goede ontkoppeling van aktieve componenten 
reduceert component ruis en voedingstransien- 
ten. Door voedingstransienten te reduceren 
wordt de emissie van de signaallus welke door 
de voedingslijnen wordt gevormd gereduceerd. 
Alhoewel de keuze van het type ontkoppeling 
grotendeels door het circuit bepaald worden is 
de technologie van het van de componenten de 
belangrijkste factor voor de keuze van het type 

W pae 


ontkoppelcondensator. 
E 
mu i ja 
Hc Bold 


x v 


Impedantie van voedingsvlakken. 

Een voedingsvlak kan overmatig geperforeerd 
worden door componentpennen, doormetalise- 
ringen en thermal reliefs. Dit heeft het effect dat 
de impedantie van het vlak in dit gebied toe- 
neemt, hetgeen er toe leidt dat retourstromen 
niet meer hun ideale weg zullen volgen welke 
een toename van de EMI tot gevolg heeft. 













5.5 Snelle Logica. 


Afsluiting. 

Elk spoor heeft een kritieke maximale lengte 
waarboven reflecties meer effect hebben. Dit 
gebeurt als de reflectietijd van het spoor de stijg- 
tijd van het signaal nadert. Het is beter om spo- 
ren een afsluiting te geven als dit gebeurt. Dit 
algoritme maakt gebruik van de fieldsolver om 
de propagatievertraging te berekenen. 


Spoorlengte. 


Sporen welke snelle signalen vervoeren moe- 


ten zo kort moge- 
lijk gehouden 
worden. Dit algo- 
ritme berekent de 
Termination Verhouding tus- 
sen de ideale ( 
manhattan ) af- 
stand en de wer- 
kelijke spoor- 
lengte en signa- 
leert sporen 
welke significant afwijken van deze lengte. 





Afschuinen van hoeken. 
Electromagnetische emissies zijn speciaal bij 
snelle signalen meer geconcentreerd op rechte 
hoeken. Het afschuinen van hoeken helpt het 
aantal scherpe hoeken te reduceren en geeft 
daardoor minder emissie. 








Overspraak. 

Overspraak wordt veroorzaakt door parallelle 
sporen. Een verandering van toestand van een 
signaal kan interferentie veroorzaken op een 
ander spoor ten gevolge van wederzijdse induc- 
tie of capaciteit. Hierbij zijn twee typen van over- 
spraak mogelijk : 
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Achterwaartse overspraak 

Deze vorm van overspraak is meestal primair. 
Het geïnduceerde signaal ontstaat op de pas- 
sieve lijn en loopt in omgekeerde richting over 
de lijn. Het geïnduceerde signaal heeft altijd de 
zelfde polariteit als het aktieve signaal. 


Voorwaartse overspraak 

Dit is een 
secundair 
E p ef recat 
qa gq eI Ke 
kward Crosstal hoofdza- 

kelijk o 
y A i x de buiten 
pn lagen van 
Og het bord 
‘or voorkomt. 
Bij voor- 


waartse overspraak loopt het signaal in de zelfde 
richting als het aktieve signaal en is meestal van 
tegengestelde polariteit. 


Impedantie van sporen. 

e impedantie van sporen wordt bepaald door de 
diameter 
van het 

m spoor en 
het omlig- 
tall gende 
medium. 

Dit algo- 

w ritme con- 

troleert 

door mid- 

del van de fieldsolver of alle sporen aan de ge- 

stelde eisen voldoen. Hiertoe berekent de field- 
solver van alle spoorsegmenten de impedantie. 


Stroom. 

De stroom die door het ontwerp kan lopen wor- 
den bepaald door de spoordiameter van de 
voedingssporen. Deze sporen moeten vol- 
doende dik zijn om de schakeling de stroom te 
kunnen geven die het nodig heeft om goed te 
werken. Dit algoritme bereken de capaciteit van 
de voedingssporen en vergelijkt dit met de be- 
nodigde capaciteit 


Jos van Heesen 

Koning & Hartman Professionele Meet- 
en Testtechniek 

Tel: 0162-480100 





Nieuwe ontwikkelingen bij PCB 


design. 


Shape-based databases, rules driven design en integratie. 


Door de snelle ontwikkelingen in de hedendaagse ontwerp-methoden en 
implementatietechnieken zijn ook de makers van CAD systemen ge- 
dwongen tot innovatie. In dit korte artikel willen we graag enkele nieuwe 
trends bespreken en de toepassing hiervan in een CAD systeem voor 
PCB (Printed Circuit Board) Layout. 
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3 chie van design-rules mogelijk. Ook het ge- 
Shape-Based vs. Grid Map bruik van complexe rules voor bijvoorbeeld 


overspraak (cross-talk) en gebalanceerde 
netten (balanced-pairs) past binnen dit con- 
cept. 


De voordelen van Shape-based Design to- 
nen zich al snel bij de toepassing in Auto- 
en Dynamische Routers. In plaats van te 











proberen een route te vinden volgens een 

















Aan de hedendaagse produkten worden steeds 
meer en steeds zwaardere eisen gesteld. Niet 
alleen moet alles steeds kleiner, sneller en goed- 
koper maar er worden ook stringente eisen ge- 
steld aan bijvoorbeeld het EMCgedrag. Alsof dit 
nog niet genoeg is moet de ontwikkeltijd ook 
steeds korter zijn. Deze eisen hebben geleid tot 
geheel nieuwe implementatietechnieken op 
componentennivo (ASIC’s, FPGA’s) maar ook 
op het PCB nivo. Hierbij zijn de CAE- en de CAD 
wereld steeds meer naar elkaar toegegroeid, er 
moet bij de fysieke implementatie met steeds 
meer ontwerp-regels rekening worden gehou- 
den die al in de CAE omgeving vastgelegd zijn. 
Bovendien moet de ontwikkelaar bij de imple- 
mentatie steeds meer woekeren met de beschik- 
bare ruimte op het PCB en steeds beter reke- 
ning houden met bijvoorbeeld transmissielijn- en 
EMC effecten. De laatste jaren zijn er enkele 
trends zichtbaar die hier op inhaken en lang- 
zaam hun weg naar de ontwerper vinden. 


6.2 Shape-Based databases 
en design. 


Als voorlopers in de markt hebben mr. Cooper 
en Chyan ingezien dat de klassieke database 
technologie geen oplossingen meer biedt voor 
de hedendaagse complexe PCB ontwerpen. Zij 
zijn de grondleggers van het Shape-Based da- 
tabase concept. 

Bij het klassieke (grid-based) systeem dat door 
nog vrijwel alle CAD systemen gebruikt wordt 
bestaat de database uit een groot ‘raster’ ook 
wel de grid-map genoemd. Op elk kruispunt in 
dit raster kan een database element aanwezig 
zijn, bijvoorbeeld een via, of een deel van een 
printspoor. De nadelen van een grid-based da- 
tabase worden het eerst duidelijk bij de toepas- 
sing van zowel through-hole als SMD compo- 
nenten. Doordat deze uitgaan van een verschil- 
lend raster (mill’s versus metric) is het zeer moei- 
lijk een gemeenschappelijk raster te vinden waar 
beide componenten op passen. De gebruiker 
wordt gedwongen om een zeer fijn raster te kie- 
zen dat niet alleen zeer lastig te gebruiken is, 
maar ook zeer veel geheugen gebruikt. 


Als alternatief wordt in een shape-based data- 
base de vorm van de complete objecten en hun 
locatie in de database vastgelegd. In dit model 
is de Shape het meest primitieve element. le- 
dere via, pin, segment, ... gebruikt een of meer- 
dere Shapes en iedere Shape krijgt d.m.v. de- 
sign rules de eigenschappen van het object die 
hij vertegenwoordigt. Bijvoorbeeld, een net om- 
vat verschillende objecten zoals pinnen, seg- 
menten en via’s. Als dit net een bepaalde 
Clearance Rule heeft, krijgt ieder object van dit 
net deze Clearance. De Shape-based Database 
modelleert iedere Shape in zijn meest exacte 
vorm. Bovendien kan dit model met zeer com- 
plexe Design Rules werken. Aan elk object kan 
een vrijwel onbeperkt aantal design-rules wor- 
den gekoppeld, dit maakt een complete hiérar- 
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— 78000 Total grid locations 
31200 Grids marked 





grid, zal de Router potentiéle routes verge- 
lijken met Shapes die zich in zijn omgeving 
bevinden. De ruimte om een spoor te leg- 
gen tussen twee objecten is alleen 
gelimiteerd door de afstand tussen de ob- 
jecten en de clearance samen met de 
breedte van de baan. Ook bij een Shape- 
based router worden kostenfactoren ver- 
geleken met als doel de meeste economi- 
sche oplossing te vinden. Tegelijkertijd wor- 
den de bestaande routes continu geévalu- 
eerd en op een strategische manier opnieuw 
gelegd voor een maximale optimalisatie van het 
design. 


Een ander groot voordeel van Shape-based 
Design ligt zoals gezegd in een dramatisch ge- 
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reduceerde hoeveelheid informatie ten opzichte 
van de Grid-based Designs. Met Shape-based 
Design, blijft de informatie lineair groeien met 
het aantal Shapes dat wordt gebruikt in het ont- 
werp. Dit betekent een optimaal gebruik van het 
geheugen en van de beschikbare rekenkracht. 


Tot nu toe waren de voordelen van Shape-based 
design alleen te vinden in auto-routers als bij- 
voorbeeld de Spectra router van Cooper & 
Chyan Technology. In 1995 echter heeft Pads 
Software een PCB-layout systeem geintrodu- 
ceerd (PowerPCB) dat geheel opgezet 

is rond een Shape-based database met 

alle voordelen die hieruit voortvloeien. 


Een extra voordeel is dat het voor de 
maker van het CAD systeem veel mak- 
kelijker is de (object-georiënteerde) 
ontwerpdatabase uit te breiden met 
nieuwe functies. Zo werkt men bij Pads 
software momenteel aan MCM onder- 
steuning, hoogfrequent ontwerp en 
EMC simulatie. Uiteraard is ook de kop- 
peling van een Shape-based autorouter 
met een shape-based layoutpakket een 
robuustere oplossing dan wanneer alle 
shape-based informatie weer op een 
grip ge-’mapped’ moet worden. 
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6.3 Rules Driven Design. 


Bij de eisen die gesteld worden aan de heden- 
daagse ontwerpen is de toepassing van één set 
design-rules bij lange na niet meer voldoende. 
Zo wil de ontwerper graag aparte regels kun- 
nen opstellen voor de verschillende deel- 
ontwerpen (classes) binnen een systeem, bij- 
voorbeeld voor de voeding, het analoge deel en 
het digitale deel. Bovendien is het handig om 
regels te kunnen koppelen aan bepaalde kriti- 
sche netten, bijvoorbeeld een voedingsnet dat 
een hoge stroom voert en dientengevolge een 
grote dikte moet hebben. Bij de meer geavan- 
ceerde ontwerpen zijn er soms regels nodig die 
forceren dat bepaalde netten een gelijke elek- 
trische lengte hebben, denk hierbij aan een klok- 
distributie-net, of regels die de EMC eigenschap- 
pen beschrijven. Als we al deze regels bij el- 
kaar nemen ontstaat een hele hiërarchie van 
design-rules die op elk nivo verschillende para- 
meters omvat. 


In het geval van het Pads PowerPCB systeem 
omvat dit op elk nivo regels voor de clearance, 
lijndikten, autorouting en hoog-frequent regels 
(cross-talk, max/min delay, route length) . Uiter- 
aard moeten deze regels tijdens het gehele 
PCB-layout proces toegepast worden. Denk 
hierbij aan de On-Line Design-Rule Check 
(DRC), tijdens het handmatig routen, tijdens het 
autorouten en het automatisch ‘gieten’ van aard- 
vlakken. De ruleset van het PowerPCB systeem 
staat tevens toe de complexe regels voor de CCT 
autorouter in te voeren en door de geven aan 
deze batch-autorouter wat het grote nadeel van 
deze krachtige autorouter wegneemt (Veel 
mogelijkheden zijn namelijk handig, maar zon- 
der goed overzicht raakt men als gebruiker al 
snel het overzicht kwijt) en de garantie biedt dat 
gedurende het gehele implementatieproces van 
de zelfde rule-set gebruik wordt gemaakt. 


De eerder genoemde hoogfrequent regels zijn 
bedoeld om te worden doorgegeven aan de in 
PowerPCB geïntegreerde EDC (Electro- 
Dynamic Check) module en aan de EMC en 
transmissielijnsimulatoren die aan het pakket 
gekoppeld kunnen worden. Bij de eerstge- 
noemde verificatie bekijkt het systeem aan de 
hand van een aantal vuistregels en parameters 
van het PCB (diëlectrische constante, dikte van 
de materialen) in combinatie met de designrules 
of er (en zo ja, waar....) transmissielijn- of over- 
spraakeffecten te verwachten zijn. 


6.4 Integratie 


Uiteraard is het noodzakelijk dat we de design- 
rules zo veel mogelijk al in de CAE omgeving 
(het schema) in kunnen voeren en deze auto- 
matisch kunnen meenemen naar het PCB-layout 
systeem en de eventuele autorouter. Het apart 
invoeren van de design-rules kost immers niet 
alleen veel tijd, maar geeft ook aanleiding tot 
het maken van fouten. De integratie tussen het 
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CAE front-end en de PCB-layout omgeving gaat 
dan ook verder dan het doorgeven van een zgn. 
netlist. 

Integratie tussen het front-end en de layout 
omgeving is natuurlijk het eenvoudigst als beide 
omgevingen van dezelfde fabrikant afkomstig 
zijn. Dit betekent echter voor de eindgebruiker 
dat deze zeer beperkt wordt in de flexibiliteit van 
de ontwikkelomgeving en de vrijheid van zijn 
keuzen. Bovendien blijkt in de praktijk dat de 
beste CAE systemen worden geleverd door fa- 
brikanten die geen PCB-layout systeem in het 
pakket hebben, en dat de fabrikanten van de 
toonaangevende PCB-layout tools voor de PC 
geen compleet CAE systeem aan bieden. 
Recentelijk zijn de MS-Windows en Windows- 
NT besturingssystemen echte multi-tasking 
omgevingen geworden die IPC (Inter-Process 
Communicatie) mogelijk maken en we zien dan 
ook dat er hard gewerkt wordt aan een betere 
integratie tussen de CAE en CAD systemen. Als 
voorbeeld van wat mogelijk is willen wij de mo- 
gelijkheden van de integratie van het VIEWlogic 
CAE systeem en het Pads PowerPCB pakket 
noemen. Het PowerPCB systeem is echter ook 
te integreren met andere CAE front-end’s als 
bijvoorbeeld Synario van Data I/O, OrCAD, 
Intergraph, MicroSim en Capilano. Een voordeel 
bij de integratie van de VIEWlogic en de Pads 
Software produkten was dat beide fabrikanten 
in het zelfde marktsegment opereren en beiden 
een duidelijke strategie hebben voor de integra- 
tie onder MS-Windows (Windows-95 en -NT). 


VIEWlogic levert de Pads PowerPCB interface 
gebundeld met alle VIEWlogic office pakketten, 
waarmee niet alleen de ‘net-list (interconnects 
en parts-list) doorgegeven kan worden, maar 
ook de design-rules en de informatie die nodig 
is voor het doorvoeren van wijzigingen 
(Backannotation & forward ECO). Deze design 
rules omvatten de gehele hiérarchie van rules 
met daarin de clearance, routing en ook de High- 
speed design- 

rules. Vorige maand is bovendien de nieuwe IPC 
interface geintroduceerd die gezamenlijk met 
VIEWlogic is ontwikkeld waarbij gebruik ge- 
maakt wordt van OLE voor de zgn. Cross- 
Probing tussen de twee systemen. Hierbij is het 
mogelijk om bijvoorbeeld in het schema (in 
VIEWlogic) een component te selecteren, dat 
vervolgens automatisch in PowerPCB opgepakt 
kan worden om het een plaats op het PCB te 
geven. Ook is het mogelijk de om via dit IPC 
kanaal het doorgeven van de wijzigingen naar 
het schema (back-annotation) automatisch uit 
te voeren. Bovendien kunnen de uit de 
VIEWlogic omgeving afkomstige design-rules 
direct doorgegeven worden aan de CCT 
autorouters of de EMC simulatiepakketten van 
Hyperlynx en Quad Design. 


Later dit jaar wil men de tweede fase van de 
integratie afronden waarbij het doel is om een 
volledige synchronisatie van de PowerPCB en 
de VIEWlogic databases te realiseren. Hierbij 
volgt het systeem de wijzigingen die gemaakt 


worden (ECO’s) en voert deze direct door in de 
andere omgeving. Hierbij wordt verder ontwik- 
keld op de reeds ontwikkelde Inter-Process 
Communicatie via de windows OLE functies. 


6.5 Conclusie 


Hoewel er aan de ontwikkelaar van complexe 
systemen steeds zwaardere eisen worden ge- 
steld, zijn er ontwikkelingen gaande die inspe- 
len op zijn behoeften. De ontwikkeling van sys- 
temen die top-down design mogelijk maken in 
een geintegreerde omgeving en de introductie 
van nieuwe concepten als de Shape-based da- 
tabase bieden niet alleen oplossingen voor de 
huidige problemen die de ontwikkelaars tegen 
komen bij de implementatie van complexe ont- 
werpen, maar belooft door de vrijwel onbeperkte 
mogelijkheden van de Design- 

rules ook oplossingen voor Design For 
Manufactoring (DFM) en lastige implementatie 
technieken als RF-design en Multi-Chip Modu- 
len. Tevens is de integratie tussen standaard 
front-end’s en PCB-layout pakketten op de PC 
‘volwassen’ aan het worden zodat economische 
alternatieven voor de dure high-end UNIX-sys- 
temen nu beschikbaar zijn. Opvallend hierbij is 
dat grote concurrentiedruk bij de PC systemen 
geleid heeft tot een sterke innovatie waardoor 
deze systemen op verschillende gebieden zelfs 
een voorsprong hebben genomen. 
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LOWEST POWER 2.7V, 12-BIT ADC 
EXTENDS BATTERY LIFE 150% 


Draws Less than 0.7mA at 100ksps! 


In portable battery-powered applications which demand minimal battery count and maximum battery life, 
obtaining the required performance using the lowest power is critical. The 12-bit MAX147 works with +2.7V to 
+5.25V supplies and samples at up to 133ksps while providing the lowest power dissipation of any 

















comparable converter. SAVE POWER OVER 
THE NEAREST COMPETITION 
¢ Guaranteed 2.7V Operation R 
+ 1pA Shutdown Mode = 4 
e Space-Saving 20-Pin SSOP Package z ; 
¢ Serial Interface Compatible with SPI™, 
QSPI™, and Microwire™ g i 
æ 8 Single-Ended or 4 Differential Inputs ae 
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SPI and QSPI are trademarks of Motorola. Microwire is a trademark of National Semiconductor. 


FIRST 2.7V 10-BIT ADC 
USES LOWEST POWER 


MAX148: 
e +2.7V to +5.25V Operation 


+ Ultra-Low Supply Current: 
0.9mA @ 133ksps 
100A @ 10ksps 


+ 1pA Power-Down Mode 
THE MAX148 OFFERS 
THE LOWEST POWER 10-BIT SOLUTION œ 8 Single-Ended/4 Differential Inputs 
i | HHH ¢ 3-Wire Serial Interface 
e 20-Pin SSOP Package 


+ Pin-Compatible 12-Bit Upgrade 
(MAX147) 
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PORTABLE INSTRUMENTS || |S 
BATTERY MANAGEMENT 
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Gratis A/D Converter Design Guide 
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Maxim Integrated Products - U.K., Maxim is een geregistreerd handelsmerk van 
phone (01734) 303 388; fax (01734) 305 577 Maxim Integrated Products 
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TELECOMMUNICATIE EN INDUSTRIELE ELEKTRONICA 


ENERGIEWEG |, POSTBUS 125, 2600 AC DELFT, TELEFOON 015-2609906. FAX 015-2619194. Getronics Group 
































\ 


AC TRAINING 





deze cursus een duidelijk hta heeft op de vragen: 


1. Welke normen zijn op onze produkten van toepassing? 

2. Is pre-compliance testen een alternatief? 

3. Welke meetopstellingen zijn nodig voor onze produkten? 06-022 3444 
4. Afgeschermde ruimte; geleidings- en/of stralingsmethode no ig? België: 0800-71937 


Deze doelstelling wordt gekonkretiseerd door elke deelnemer één of meerdere cases in te 

laten brengen, welke in de cursus worden behandeld. Een praktisch cursusboek is bij de 

prijs van f 925,--/19390 BF (excl. BTW) inbegrepen. De cursus is met name bedoeld voor 

technici op HBO denk- en werknivo, betrokken bij testen en kwaliteitscontrole. Voorkennis 
is ni | n gedetailleerde agenda is op an dar ei an 


NN ULTImate Technology levert voor slechts f 7895,-/ 157.900 BF (excl. BTW) een pre-compliance _ 

_ EMC-testset, bestaande uit een 1 GHz software-controlled Spectrum Analyzer met tracking — 
~“/ generator, speciale probe, 1 GHz breedbandversterker, LISN/kunstnet (power dummy) en een 
impulsbegrenzer. Optionele netwerken, ESD test guns en antennes zijn uiterst scherp geprijsd. 
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